Repository navigation
Conversation
receive queued the completion's acknowledgement and exited before Nirux recorded it, so a receive run right away printed the same completion again until the queue was drained. It now waits for that record, like reply waits for its answer. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ent does The test drained once after a fixed delay, so a slow machine could miss the acknowledgement. It now drains until the completion is recorded, while the two receives run back to back. confirmationTimeout sits before pollInterval, as in reply. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
TLDR:
--mission receiveprinted the samecompletedevent again and again. It now waits until Nirux records the acknowledgement before it exits.Problem
receiveprinted a completion, queued its acknowledgement, and exited at once. Nirux applies that queue a moment later (0.15 s debounce), so areceiverun right away still read the completion as unconsumed and printed it again. A parent looping onreceivegot each finished Mission 6 to 8 times. The ledger shows it: the four completions in the report were marked consumed 0.15 s apart, once the queue was finally drained.Questions were fine because
replyalready waits for Nirux to confirm.Solution
After queueing the acknowledgement,
receivewaits for the ledger to record it (up to 5 s, the same bound asreply). Args, exit codes and JSON output are unchanged. New testtestReceiveDeliversACompletionOnceWhenRunAgainRightAwayfails without the fix (secondreceivereturned 0, the same event) and passes with it.🤖 Generated with Claude Code