Repository navigation
fix: keep subagents in spawn order in the Agents panel - #151
Merged
Merged
Conversation
Each agent's task.progress row is replaced on every tick, and thread snapshots keep only the newest 500 activities, so busy fleets lose their task.started rows. The panel then ordered agents by their latest progress time and moved each one to the bottom whenever it ran a tool. Ingestion now stamps the task's spawn time on its progress rows (cached per task, falling back to persisted rows after a restart), and the client fold orders and times agents from it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This was referenced Oct 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Agents panel is meant to list subagents in spawn order, but with a busy fleet the rows kept moving: each agent dropped to the bottom whenever it ran a tool call, and the elapsed timers reset to a few seconds.
Three things combined to cause it:
firstSeenAt) is the time of the oldest activity row the client holds for that agent.task.startedrow was 778–2,919 rows deep, so none of them reached the client.task.progressrow has a fixed id and is replaced on every tick. That keeps it in the window, but it makes it the agent's "first seen" row. Every update gave the agent a newfirstSeenAt, so it re-sorted to the end. ItsstartedAtcame from the same row, which is why the timers were wrong.Fix
spawnedAt. The time is cached per task whentask.startedarrives. On a cache miss (restart, TTL or eviction), a new repository query,getTaskSpawnedAt, reads the earliest start or stamped progress time from the database, which still has every row. If there is none, the first observed time is used and cached, so the value stays stable.foldSubagentActivitiessorts byspawnedAtwhen it is earlier than what it has seen. If a progress row is the first thing it sees for an agent, it also usesspawnedAtas that agent'sstartedAt. Web and mobile share this fold.Workflow members sort on the same key, so they get the same fix.
Tests
subagentRuntime.test.ts)ProviderRuntimeIngestion.test.ts)getTaskSpawnedAtreads it from a start row, from a stamped progress row, and returns none for an unknown task (ProjectionThreadActivities.test.ts)🤖 Generated with Claude Code (Claude Opus 5.5, T3 Code)