Sign up
View stargazersSign up

[Bug]: Toggling a scheduled task shuffles task list and swaps rows under cursor#16390

openedOct 6, 2026byMMchicao

Area

apps/server

Steps to reproduce

  1. Create at least two scheduled tasks in Settings -> Scheduled tasks (or have multiple automations attached to a thread).
  2. In the scheduled tasks list, toggle the enabled switch on the second task.
  3. 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.

JJulius MarmingeOct 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.selectAllRows orders by updated_at DESC, task_id ASC. setEnabled stamps updated_at to now and calls notifyChanged, and subscribeList re-emits list() on that signal.
  • The same stamp happens when a run starts or finishes (markRunning / markCompleted), on a missed-run reschedule, and on save, so rows can also jump while a task runs.
  • Web settings (ScheduledTasksSettings), the thread Automations section, mobile settings and list_scheduled_tasks all 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.
  • listDueTasks is 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

  • Sorting the visible list by a column that toggles and runs don't rewrite would keep rows in place. created_at ASC, task_id ASC (as in #16392) is one option. created_at DESC is another, and would keep newly created tasks at the top like they appear today.

A maintainer will decide on the fix direction.