Show the pending-question glyph while a thread's runtime is active#864
Merged
Conversation
A thread blocked on AskUserQuestion keeps its runtime `active` for as long as the question is open, so ranking "runtime" first in `resolveThreadListIndicator` made the spinner win every time and left the CircleQuestion glyph unreachable in the sidebar. Restore the pre-#828 ordering and demote only the three ambient work signals — workflow, background-agent, and background-command — below the spinner. That keeps #828's intent (the spinner beats work the row can't otherwise explain) while attention states, working-draft, plan, and goal sit above it again as they did before. Co-Authored-By: Claude <noreply@anthropic.com>
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
1 participant
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.
Summary
A thread blocked on
AskUserQuestionkeeps its runtimeactivefor as long as the question is open. #828 madeisRuntimeActivethe top ofresolveThreadListIndicator, so the spinner won that race every time and theCircleQuestionglyph became unreachable — the sidebar never showed that a thread was waiting on you.Verified against real data rather than inferred: for thr_zqfgksiw39, pending interaction
pint_h2mmtg9wpb(kind: user_question) was open from1784843793813to1784843949375, and a screenshot taken at1784843844010— inside that window, with the thread atstatus: active/displayStatus: active— shows a spinner on the row.This restores the pre-#828 ordering and demotes only the three ambient work signals below the spinner, which is the narrower fix #828 was reaching for:
unread-errorwaiting-for-inputworking-draftplan-modegoalruntimeworkflowbackground-agentbackground-commanddraftunread-successNet effect versus pre-#828 is only that
workflow,background-agent, andbackground-commandmoved from above the spinner to below it.Behavior reverted from #828
Both were asserted by tests #828 added, so those tests are rewritten here:
ListTodo/Targetagain, not the spinner. Both useanimate-shine-icon, so the row still reads as working.Test changes
9 tests across 5 files encoded #828's spinner-first order. The three "uses shared runtime precedence" tests (collapsed-section rollup, thread search, mobile recents) keep their fixtures and just flip which glyph wins — they still prove those surfaces defer to the shared helper. Added a
ThreadRowtest for the actual reported case: pending interaction + active runtime rendersCircleQuestion.Known gap (not addressed)
SplitPaneMiniMap(#862) replaces the entire trailing glyph slot for a thread open in a split, so a pending question there still shows no question mark.Tests
pnpm exec turbo run test --filter=@bb/app --force— 283 files, 2079 tests passingpnpm exec turbo run typecheck lint --filter=@bb/app— typecheck clean, lint 0 errors (151 pre-existing warnings)🤖 Generated with Claude Code