fix(cli): avoid stale Swarm activity notices after reads - #13709
Merged
Conversation
marius-kilocode
enabled auto-merge
September 2, 2026 18:54
kirillk
approved these changes
Sep 2, 2026
This was referenced Sep 6, 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.
What Problem This Solves
A successful
board_readcould return a peer message and immediately attach an activity notice for that same message. That notice could cause another unnecessary read even though no new message had arrived.Fixes #13671. Part of #13673, built on the merged #13629 prototype. This PR contains only the notice/read correction and focused regressions, not the other Swarm milestone work.
Why This Change Was Made
The existing notice check did not account for the cursor returned by a successful explicit read. It now excludes activity through that cursor within the same board, while still checking activity after the returned page. The existing success boundary, permission checks, cancellation checks, and loop-local notice cache remain in place.
This does not disable notices on every
board_read. A partial page or a post arriving after the read snapshot can still produce a fixed activity notice. Message bodies remain behind explicitboard_readcalls. History pagination remains separate from notice progress, and restarting a loop can still re-advertise history under the existing advisory behavior. This is not durable acknowledgement or exactly-once delivery.User Impact
Before:
After:
Unread messages on later pages and concurrent posts remain discoverable. Failed or cancelled reads do not advance successful consumption. No tools, settings, UI, identity metadata, timers, wake-ups, or protocols are added.
Evidence
bun test ./test/kilocode/board-context.test.ts ./test/kilocode/board-tools.test.ts ./test/kilocode/board/store.test.ts ./test/kilocode/board-live.test.tsfrompackages/opencode: 42 passed, 0 failed, 339 assertions.bun run typecheckfrompackages/opencode: passed.bun run linton the four changed TypeScript files: 0 warnings, 0 errors.bun run script/check-opencode-annotations.ts --worktree: passed, no shared upstream source files changed.git diff --check: passed.The smoke tests use the real prompt runtime, board tools, database, and model-facing tool-result conversion with a local simulated LLM. They confirm that a successful read has no stale notice on either the read or the next normal tool result, while a failed read preserves the notice on the next normal tool result. Focused tests cover count- and byte-limited pages, concurrent posts, cancellation, permissions, and loop-cache reset behavior.
Testing limit: This was not manually exercised in the VS Code UI or with a live model. No performance or token-saving measurement is claimed.
Manual check: Have a worker post, read that message before receiving its notice, then run a normal tool. Neither result should advertise the consumed activity again. Repeat with a one-message page and with a post arriving during the read; unread activity should still be announced.