jerry/buzz

mirror of https://github.com/block/buzz.git synced 2026-11-07 01:41:06 +00:00

Files

Duncan 9659800934 fix(acp): classify channel_full as transient in transcript reducer

handlePermissionDecisionResult treated every non-sent/already_decided
status as an authoritative delivery failure, incrementing deliveryFailed
and triggering the PermissionDecisionButtons useEffect to call
setPending(null). With channel_full now keeping the retransmit orchestrator
alive, this caused two concurrent delivery loops for the same nonce: the
original retransmit loop still subscribed, plus a second loop from the
newly re-enabled button click.

Add channel_full as an early-return alongside sent/already_decided in the
reducer. Both channel_full producers (mixed owner-Full/sibling-Sent and
pure-Full) are transient queue-saturation conditions; the orchestrator
handles resend automatically and the card must stay disabled until the
retry settles or the deadline expires.

Update LifecycleActivity.tsx deliveryFailed prop doc and the re-enable
comment to name the three authoritative statuses (no_active_turn,
channel_closed, no_channel) and explain that channel_full does not
increment the token.

Tests:
- Fix buildTranscript_control_result_second_failure_increments_delivery_failed
  to use no_channel for the second failure (channel_closed would still work,
  but channel_full was the prior value and is now transient)
- Add buildTranscript_control_result_channel_full_does_not_mark_delivery_failed:
  transcript 79→80; mutation (removing the guard) → test red at expected
  undefined got 1
- Add test_channel_full_reducer_to_component_buttons_stay_disabled in
  LifecycleActivity.render.test.mjs: drives full pipeline acp_read →
  buildTranscript → click → channel_full through reducer → assert both
  buttons stay disabled + no second delivery starts; companion case
  (no_active_turn) asserts buttons DO re-enable; mutation → red at disabled
  assertion

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>

2026-09-02 14:31:57 -04:00