multi: Report empty round-join as no-op, not INTERNAL - #1007
Conversation
In this commit, we stop a refresh or leave that queued nothing from
failing its follow-on round join with a confusing INTERNAL error. An
`ark vtxos refresh --all` (or `leave --all`) with no live VTXOs, or any
selection that resolved to nothing, returns a clean queued no-op from
RefreshVTXOs -- but the CLI then auto-joined the next round, and
JoinNextRound failed with:
INTERNAL: join next round: failed to trigger round registration:
no pending round for event *round.IntentRequested
an error that named neither cause nor fix.
The round actor produced that condition as a bare fmt.Errorf, so no
caller could tell the benign "nothing was queued" case apart from a
genuine fault. We give it a typed ErrNoPendingRound sentinel, wrapped
with %w through TriggerRoundRegistration. JoinNextRound now maps it to a
clean JoinNextRoundResponse{Status: "nothing_to_join"} instead of
codes.Internal, and the CLI's auto-join prints "nothing queued to join"
rather than surfacing an error.
Found while manually testing #987.
Roasbeef
added
the
backport-v0.1.x-branch
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request gracefully handles the case where an auto-join is triggered but there are no pending rounds or queued VTXOs. It introduces a typed ErrNoPendingRound error, which the RPC server intercepts to return a benign nothing_to_join status instead of an internal error. The CLI is updated to handle this status and print a friendly message. Comprehensive unit tests have been added to verify these changes. I have no additional feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
Successfully created backport PR for |
…ranch [v0.1.x-branch] Backport #1007: multi: Report empty round-join as no-op, not INTERNAL
1 participant
In this PR, we fix a third bug found while manually testing #987 on the
arktest regtest harness: a refresh or leave that queued nothing still
auto-joins the next round, and that join fails with a confusing
INTERNALerror instead of a clean no-op.The bug
ark vtxos refresh --all(orleave --all) with no live VTXOs — or anyselection that resolves to nothing — correctly returns a queued no-op
from
RefreshVTXOs. But the CLI then auto-joins the next round, andJoinNextRoundfails:The command exits 1 with an error that names neither the cause nor the
fix, even though nothing actually went wrong — there was simply nothing
to join.
Observed on the live daemon:
refresh --all --yeswith an empty walletprints the
queuedno-op JSON, then theINTERNALabove; with thischange it prints
nothing queued to joinand exits 0.The fix
The round actor produced the "no pending round" condition as a bare
fmt.Errorf, so no caller could tell this benign "nothing was queued"case apart from a genuine internal fault. We give it a typed
ErrNoPendingRoundsentinel, wrapped with%wthroughTriggerRoundRegistration.JoinNextRoundnow maps it to a cleanJoinNextRoundResponse{Status: "nothing_to_join"}instead ofcodes.Internal, and the CLI's auto-join step printsnothing queued to joinrather than surfacing an error. An explicitark rounds joinwithnothing queued gets the same clean treatment.
Validation
roundtest: a server message with no pending round fails with atyped error (
errors.Is(..., ErrNoPendingRound)).cmd/waveclitests:maybeJoinNextRoundreportsnothing_to_joinas a no-op, and an ordinary join still prints the join notice.
roundandcmd/wavecli/waveclicommandspackages under-race.make fmt-changed-check,make lint-changed-local(0 issues),make commitmsg-lint,make build.--all --yesnowreports the no-op cleanly).
Found while manually testing #987.