P1: chief and assistant echo RESULTs on a relay thread (ui797 thread 40df75c5, 54 messages) #1847

Closed
opened 2026-11-06 19:48:02 +00:00 by jason.woltje · 1 comment
Owner

Filed by the MVP3 lead #797 agent for the Lead (Mos), key roundb-2-halt. Source: ui797 Round B, campaign3, 2026-11-06. Evidence is under /mnt/storage/scratch/mosaic-lead/mvp3/step14/round-b/c3halt/ (thread4.txt, busnotice.txt, busnotice2.txt, haltrep.txt). The store is /srv/mosaic/.mosaic-ui797/bus/bus.sqlite on .53, read only. Support tree 1186cf7b1.

What happened

Thread 40df75c5-0514-4d17-8d52-16b22ced27cc ("pomodoro request A", Round A) had no human input after the halt/resume at 19:15:01Z. Even so, the chief and the assistant exchanged 54 messages there between 19:15Z and the cap halt at 19:31:38Z:

  • chief → assistant INFO: 21
  • assistant → chief RESULT: 21 (one for each INFO)
  • chief → assistant RESULT: 12

The wake: chief rebc27bb0b748 sent RESULT seq 324 (message 635af8ef) at 19:17:10.947Z, in reply to the pre-halt assistant message edec53ed. Assistant r1ee370991943 launched at 19:17:13.202Z.

The pattern:

  1. The chief relays each event to the assistant as an INFO. Most were in_reply_to the same anchor, 2ef887b8. Examples: seq 355, 357, 361, and 363-383 ("Duplicate bus notice handled…", "Fifth duplicate notice…", through "Thirteenth duplicate notice…").
  2. The runner sends the assistant's turn output back to the chief automatically as a RESULT, because it auto-replies to every non-RESULT message (packages/harness/src/runner.mjs:668-671). That accounts for all 21 assistant RESULTs (e.g. seq 356 re 355, 359 re 357, 362 re 361).
  3. The chief takes a turn on each of those RESULTs and often sends another RESULT back, starting "Sync, no action needed" or "Crossing confirmation" (seq 385, 387, 404, 414, 416, 421, 426, 430, 432). The assistant then takes a turn on that one too.

So each event costs at least two turns, often three or four, and every turn carries the full, growing context. The halt ended the exchange; nothing in the code would have.

Cost

  • Assistant r1ee370991943: 32 turns, 1,036,184 tokens (input 99,733, output 10,371, cache_read 926,080, from the per-run usage sums in spend.txt). 36,597 of that landed after the 19:31:38Z stop. Correction: the first report (19:33:41Z) said 791,695, which was a partial count.
  • Most of the chief's 40 turns (3,492,625 tokens) between 19:22Z and 19:31Z were relays or replies on this thread.

Expected

An INFO tells the recipient something; it does not ask for an answer. A RESULT reply to a RESULT between two agents is an acknowledgement and wakes another turn for nothing. A relay to the assistant with no human question waiting should not start a cycle of answers.

MVP fix scope (fix row with the instance-running defect)

The smallest change that stops the echo, plus a regression test that reproduces the 40df75c5 pattern (chief INFO → automatic assistant RESULT → chief RESULT → …) and shows it stops after a bounded number of messages. The builder picks the mechanism after reading the code. Candidates: no automatic RESULT reply to an INFO, and/or the broker refuses an agent RESULT in_reply_to a RESULT. Any change to class semantics must keep the human/tester paths and the existing reply-protocol tests green.

P1.

Filed by the MVP3 lead #797 agent for the Lead (Mos), key roundb-2-halt. Source: ui797 Round B, campaign3, 2026-11-06. Evidence is under /mnt/storage/scratch/mosaic-lead/mvp3/step14/round-b/c3halt/ (thread4.txt, busnotice.txt, busnotice2.txt, haltrep.txt). The store is /srv/mosaic/.mosaic-ui797/bus/bus.sqlite on .53, read only. Support tree 1186cf7b1. ## What happened Thread 40df75c5-0514-4d17-8d52-16b22ced27cc ("pomodoro request A", Round A) had no human input after the halt/resume at 19:15:01Z. Even so, the chief and the assistant exchanged 54 messages there between 19:15Z and the cap halt at 19:31:38Z: - chief → assistant INFO: 21 - assistant → chief RESULT: 21 (one for each INFO) - chief → assistant RESULT: 12 The wake: chief rebc27bb0b748 sent RESULT seq 324 (message 635af8ef) at 19:17:10.947Z, in reply to the pre-halt assistant message edec53ed. Assistant r1ee370991943 launched at 19:17:13.202Z. The pattern: 1. The chief relays each event to the assistant as an INFO. Most were in_reply_to the same anchor, 2ef887b8. Examples: seq 355, 357, 361, and 363-383 ("Duplicate bus notice handled…", "Fifth duplicate notice…", through "Thirteenth duplicate notice…"). 2. The runner sends the assistant's turn output back to the chief automatically as a RESULT, because it auto-replies to every non-RESULT message (packages/harness/src/runner.mjs:668-671). That accounts for all 21 assistant RESULTs (e.g. seq 356 re 355, 359 re 357, 362 re 361). 3. The chief takes a turn on each of those RESULTs and often sends another RESULT back, starting "Sync, no action needed" or "Crossing confirmation" (seq 385, 387, 404, 414, 416, 421, 426, 430, 432). The assistant then takes a turn on that one too. So each event costs at least two turns, often three or four, and every turn carries the full, growing context. The halt ended the exchange; nothing in the code would have. ## Cost - Assistant r1ee370991943: 32 turns, 1,036,184 tokens (input 99,733, output 10,371, cache_read 926,080, from the per-run usage sums in spend.txt). 36,597 of that landed after the 19:31:38Z stop. Correction: the first report (19:33:41Z) said 791,695, which was a partial count. - Most of the chief's 40 turns (3,492,625 tokens) between 19:22Z and 19:31Z were relays or replies on this thread. ## Expected An INFO tells the recipient something; it does not ask for an answer. A RESULT reply to a RESULT between two agents is an acknowledgement and wakes another turn for nothing. A relay to the assistant with no human question waiting should not start a cycle of answers. ## MVP fix scope (fix row with the instance-running defect) The smallest change that stops the echo, plus a regression test that reproduces the 40df75c5 pattern (chief INFO → automatic assistant RESULT → chief RESULT → …) and shows it stops after a bounded number of messages. The builder picks the mechanism after reading the code. Candidates: no automatic RESULT reply to an INFO, and/or the broker refuses an agent RESULT in_reply_to a RESULT. Any change to class semantics must keep the human/tester paths and the existing reply-protocol tests green. P1.
jason.woltje added the bug label 2026-11-06 19:48:02 +00:00
Author
Owner

Fixed on refactor; pushed by the Lead at 20:45Z on 2026-11-06 (origin/refactor 1186cf7b1..3598839e6, fast-forward). Posted by the MVP3 lead #797 agent.

  • 4048e0f60 fix(bus,harness): the broker adds in_reply_to_class to agent inbox rows (taken from the stored parent message; message.send rejects a supplied value). The runner sends no automatic reply when an agent's non-REQUEST message replies to a RESULT. REQUEST, ordinary INFO and human/tester/user messages still get answers. The send_message description says to use class REQUEST for a follow-up. Regression test in packages/harness/tests/runner.test.mjs ("agent replies to RESULT end unless they are REQUEST…"), which fails on 1186cf7b1.
  • c04529c7b fix(bus): the review fix round. The Sol xhigh review found no defect in the #1847 part. It confirmed that message.receive is the runner's only message source, that the automatic RESULT feedback edge is broken, and that intake, completion delivery and decision/review flows use explicit relays that don't need the suppressed reply. The findings it fixed belong to #1848.

Remaining, by design: two models can still loop through explicit sends. The fix removes only the automatic edge.

Gate on c04529c7b, Node 26.12.1:

  • touched 123/0
  • bus except project-files 1648/0
  • harness 318/0
  • webui 679/0 on rerun

Evidence: /mnt/storage/scratch/mosaic-lead/mvp3/step14/round-b/fix-1847-1848-gate/.

Fixed on refactor; pushed by the Lead at 20:45Z on 2026-11-06 (origin/refactor 1186cf7b1..3598839e6, fast-forward). Posted by the MVP3 lead #797 agent. - 4048e0f60 fix(bus,harness): the broker adds `in_reply_to_class` to agent inbox rows (taken from the stored parent message; `message.send` rejects a supplied value). The runner sends no automatic reply when an agent's non-REQUEST message replies to a RESULT. REQUEST, ordinary INFO and human/tester/user messages still get answers. The send_message description says to use class REQUEST for a follow-up. Regression test in packages/harness/tests/runner.test.mjs ("agent replies to RESULT end unless they are REQUEST…"), which fails on 1186cf7b1. - c04529c7b fix(bus): the review fix round. The Sol xhigh review found no defect in the #1847 part. It confirmed that message.receive is the runner's only message source, that the automatic RESULT feedback edge is broken, and that intake, completion delivery and decision/review flows use explicit relays that don't need the suppressed reply. The findings it fixed belong to #1848. Remaining, by design: two models can still loop through explicit sends. The fix removes only the automatic edge. Gate on c04529c7b, Node 26.12.1: - touched 123/0 - bus except project-files 1648/0 - harness 318/0 - webui 679/0 on rerun Evidence: /mnt/storage/scratch/mosaic-lead/mvp3/step14/round-b/fix-1847-1848-gate/.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1847