mosaicstack/stack
1
0
Fork 1
Code Issues 105 Pull Requests 1 Actions Packages Projects Releases 15 Wiki Activity

wake/ack.sh: status --agent <name> silently reports a different lane — an agent checking its own queue is told it is empty while actionable claims wait #949

New Issue
Open
opened 2026-07-30 14:19:18 +00:00 by Mos · 0 comments
Mos commented 2026-07-30 14:19:18 +00:00
Copy Link
Copy Source

Found by the consumer on the affected lane during #944 field verification. Severity: HIGH — this is a silent wrong answer, not a usage error.

Observed

$ ack.sh status --agent mos-dt
observed_seq=0  consumed_seq=0  pending_depth=0     rc=0

True values for that lane at the same moment: 70 / 67 / 2, with an actionable claim pending.

Mechanism

The dispatcher is status) cmd_status "$@" ;; — arguments are passed through and never parsed. --agent is implemented only by embed, where it bakes a WAKE_AGENT= prefix onto the emitted ack line; it has never been a lane selector. Lane resolution is purely ${WAKE_AGENT:-default} at run time.

An arbitrary bogus flag also yields rc=0, so nothing signals the miss.

Correct invocation is the environment variable: WAKE_AGENT=<name> ack.sh status.

Why HIGH rather than cosmetic

The lane it misresolves to is default, which exists on at least one host (created 2026-07-25, every cursor zero, every file empty). So the wrong-lane read does not error — it returns a completely plausible "nothing pending".

An agent that checks its queue the natural way is told it has no work while actionable claims wait.

That is the same consumer-visible outcome as the ack-watermark defect (#946) reached by a different route, and worse in one respect: the watermark defect at least renders the entry before instructing you past it. This one reports the queue as empty.

It was nearly reported as ledger corruption. What prevented that was the reader independently holding the true value (67) and noticing the contradiction. With no second instrument in hand, three zeros are indistinguishable from a genuinely empty lane — there is no self-consistency check that catches it.

Fix — two parts, and the second matters more

  1. status should accept --agent. The flag exists elsewhere in the same CLI, so its absence here is a false affordance.
  2. Every subcommand must reject unknown flags with rc=2 instead of rc=0.

Part (2) is the general fix. An accepted-and-ignored flag is precisely what converted this from a usage error into a silent wrong answer, and it covers the next flag someone reasonably assumes exists.

Acceptance

  • ack.sh status --agent <name> reports that lane, or exits non-zero.
  • Any unknown flag on any subcommand exits rc=2 with a message naming the flag.
  • A negative test asserting that a bogus flag does not exit 0.

Related: #946 (ack watermark advances past quarantined entries). Both produce a silently under-reported queue by different mechanisms.

Found by the consumer on the affected lane during #944 field verification. **Severity: HIGH** — this is a silent wrong answer, not a usage error. ## Observed ``` $ ack.sh status --agent mos-dt observed_seq=0 consumed_seq=0 pending_depth=0 rc=0 ``` True values for that lane at the same moment: **70 / 67 / 2**, with an actionable claim pending. ## Mechanism The dispatcher is `status) cmd_status "$@" ;;` — arguments are passed through and **never parsed**. `--agent` is implemented only by `embed`, where it bakes a `WAKE_AGENT=` prefix onto the emitted ack line; it has never been a lane selector. Lane resolution is purely `${WAKE_AGENT:-default}` at run time. An arbitrary bogus flag also yields `rc=0`, so nothing signals the miss. Correct invocation is the environment variable: `WAKE_AGENT=<name> ack.sh status`. ## Why HIGH rather than cosmetic The lane it misresolves to is `default`, **which exists** on at least one host (created 2026-07-25, every cursor zero, every file empty). So the wrong-lane read **does not error** — it returns a completely plausible *"nothing pending"*. > **An agent that checks its queue the natural way is told it has no work while actionable claims wait.** That is the same consumer-visible outcome as the ack-watermark defect (#946) reached by a different route, and worse in one respect: the watermark defect at least *renders* the entry before instructing you past it. This one reports the queue as **empty**. It was nearly reported as ledger corruption. What prevented that was the reader independently holding the true value (`67`) and noticing the contradiction. **With no second instrument in hand, three zeros are indistinguishable from a genuinely empty lane** — there is no self-consistency check that catches it. ## Fix — two parts, and the second matters more 1. `status` should accept `--agent`. The flag exists elsewhere in the same CLI, so its absence here is a **false affordance**. 2. **Every subcommand must reject unknown flags with `rc=2` instead of `rc=0`.** Part (2) is the general fix. An accepted-and-ignored flag is precisely what converted this from a usage error into a silent wrong answer, and it covers the next flag someone reasonably assumes exists. ## Acceptance - `ack.sh status --agent <name>` reports that lane, or exits non-zero. - Any unknown flag on any subcommand exits `rc=2` with a message naming the flag. - A negative test asserting that a bogus flag does **not** exit 0. *Related: #946 (ack watermark advances past quarantined entries). Both produce a silently under-reported queue by different mechanisms.*
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#949