Repository navigation
[Bug]: Toggling a scheduled task shuffles task list and swaps rows under cursor #16390
Description
Area
apps/server
Steps to reproduce
- Create at least two scheduled tasks in Settings -> Scheduled tasks (or have multiple automations attached to a thread).
- In the scheduled tasks list, toggle the enabled switch on the second task.
- Observe how the rows immediately swap positions.
Expected behavior
Toggling a task should update its enabled state in place without changing the visual order of tasks in the list.
Actual behavior
ScheduledTaskService.selectAllRows orders tasks with ORDER BY updated_at DESC, task_id ASC.
When a task's enabled switch is toggled (or when a task runs), its updated_at timestamp is updated to the current time. This instantly promotes the updated task to the top of the list via the live subscription (subscribeList), causing the rows to swap positions immediately under the cursor.
Visually, the toggle switch that moved belongs to the task that was just toggled, but because it jumped to the other row's position, it appears as though toggling one task activates or deactivates another task. Clicking again then toggles the other task that shifted under the mouse.
Proposed fix
Sort scheduled_tasks by created_at ASC, task_id ASC in ScheduledTaskService.selectAllRows so that task ordering remains stable across status updates, runs, and toggles.
Activity
juliusmarminge commentedon Oct 6, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks @Mchicao for the precise report and for already pinpointing the query. This reproduces on current
main, and I see you've opened #16392 for it too.What I found
ScheduledTaskService.selectAllRowsorders byupdated_at DESC, task_id ASC.setEnabledstampsupdated_atto now and callsnotifyChanged, andsubscribeListre-emitslist()on that signal.markRunning/markCompleted), on a missed-run reschedule, and on save, so rows can also jump while a task runs.ScheduledTasksSettings), the thread Automations section, mobile settings andlist_scheduled_tasksall render this array order as-is. Rows are keyed by task id, so the switch that moves is the one that was toggled, and the next click lands on whatever row slid under the pointer.listDueTasksis a separate query (ORDER BY next_run_at ASC, task_id ASC), so changing the list sort wouldn't affect scheduler order.Likely fix area
created_at ASC, task_id ASC(as in fix(scheduled-tasks): preserve stable task order on status updates and toggles #16392) is one option.created_at DESCis another, and would keep newly created tasks at the top like they appear today.A maintainer will decide on the fix direction.