Repository navigation
Inbox: a held row's state follows a delivery; only the order waits for an action - #1772
Merged
Merged
Conversation
…s for an action The held list kept each row's whole state until the person acted, so after the agent had the reply (a wake's delivery, wait_for_reply, read_thread) the row still said "Sent · Saved for <agent>" until a reload, while the thread beside it said Delivered. A background refresh now replaces each held row in place with its current copy, unless that copy carries new agent activity, which still waits behind "N new". Sections and order stay as they were.
1 task
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.
What
Found in the 0.28.8 release smoke: after the person's reply reached the agent, the thread pane said "Delivered to Pi/OpenCode, ". The list row still said "Sent · Saved for . It sees it when it checks." for 15–30 s or longer, until a page reload moved it to Quiet. The server was already listing the thread as Quiet, with
checked_atset.Root cause
App.tsx'srefreshList(false)is the background refresh each event-stream record triggers. It keptshown, the held sections, exactly as they were, so the rows' state stayed frozen with them. The delivery and agent-read lines did reach the page through the stream and updatedlatest, which is why the thread pane was right. The row read onlyshown, which waited for the next action.Fix
refreshHeldRows(shown, latest)inpackages/inbox/held.tsis pure and runs on every background refresh. Each held row keeps its section and its position, but is replaced by its current copy, unless that copy carries new agent activity (a thread an agent started, or a newer agent message). The rule is the same oneheldNoticealready used, now factored intohasNewAgentActivity.The held-order guarantee is unchanged:
A delivered or read row, or one whose thread was resolved, shows its state as it now is, in place.
Tests
packages/inbox/held.test.ts: a delivered Sent row updates in place. The order is unchanged, and a row with a newer agent message keeps its old copy and still counts toward "N new".tests/e2e/inbox.spec.ts: new test. The person picks and Sends, and the row says "Saved for Claude Code". The agent then reads the thread, and the row becomesdata-section="quiet"and stops saying "Saved for" with no reload and no action, with the row order unchanged. It fails on main: the row stayssent, which I checked against a binary compiled from main'sApp.tsx. The restart test now looks for the holding row after the reload, because the named thread is Quiet (folded) by then.The whole inbox Playwright suite passes locally (
bun run test:e2e:inbox, 56 tests).🤖 Generated with Claude Code