Skip to content

fix(cli): avoid stale Swarm activity notices after reads - #13709

Merged
marius-kilocode merged 2 commits into
mainfrom
swarm-v2-read-notices-13671
Sep 2, 2026
Merged

fix(cli): avoid stale Swarm activity notices after reads#13709
marius-kilocode merged 2 commits into
mainfrom
swarm-v2-read-notices-13671

Conversation

@marius-kilocode

Copy link
Copy Markdown
Collaborator

What Problem This Solves

A successful board_read could 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 explicit board_read calls. 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:

Worker posts: "Parser rejects empty input."
Main calls board_read -> Message + activity notice for that same message.
Main may call board_read again -> Same message, no new activity.

After:

Worker posts: "Parser rejects empty input."
Main calls board_read -> Message only, no stale activity notice.
Main runs a normal tool -> No repeated activity notice; work continues.

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.ts from packages/opencode: 42 passed, 0 failed, 339 assertions.
  • bun run typecheck from packages/opencode: passed.
  • Scoped root bun run lint on 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.

@marius-kilocode
marius-kilocode merged commit 97df6d4 into main Sep 2, 2026
42 of 47 checks passed
@marius-kilocode
marius-kilocode deleted the swarm-v2-read-notices-13671 branch September 2, 2026 19:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Keep Kilo Swarm activity notices consistent with reads

2 participants