Skip to content

fix: Do not report a committed block as rejected on withdrawal broadcast failure - #119

Open
giaki3003 wants to merge 3 commits into
LayerTwo-Labs:masterfrom
giaki3003:fix/w3-20260621-2151-kimiclaw-confirm-glmclaw-t-thunder-rust-submit-block-commits-reorg-before-w
Open

fix: Do not report a committed block as rejected on withdrawal broadcast failure#119
giaki3003 wants to merge 3 commits into
LayerTwo-Labs:masterfrom
giaki3003:fix/w3-20260621-2151-kimiclaw-confirm-glmclaw-t-thunder-rust-submit-block-commits-reorg-before-w

Conversation

@giaki3003

Copy link
Copy Markdown
Contributor

What's wrong

In Node::submit_block (lib/node/mod.rs), the pending withdrawal bundle is broadcast after net_task.new_tip_ready_confirm(new_tip) has already returned, i.e. after the new tip is committed. The call is written as broadcast_withdrawal_bundle(..).await?, so any failure from the mainchain wallet (RPC unavailable, transport error, a bundle the wallet declines) propagates out of submit_block as an Err.

The caller cannot distinguish that from "the block was not accepted". App::mine (app/app.rs) propagates it, so the mine RPC and the GUI miner report a failure for a block that is, in fact, already the node's tip — and the operator's natural response (retry, investigate the block) is aimed at the wrong thing.

The fix

Capture the broadcast result rather than propagating it: log the existing trace on success, log at error level on failure, and return Ok(true) either way, since the tip is committed regardless. The bundle stays pending in state until the corresponding mainchain event connects it, so the next submit_block re-reads it and retries the broadcast.

No test is included — the broadcast goes through the mainchain wallet gRPC client, so covering the failure path needs integration-level plumbing. Happy to add one if you'd prefer.

Finding report (access-controlled): https://giaki3003.tech/#/findings/20260621-2151-kimiclaw-confirm-glmclaw-thunder-rust-submit-block-reorg-committed-before-withdrawal-broadcast


Part of a short series for this repo (fix 3 of 3); builds on #118, so it reads best merged after that one. Happy to rebase or split if you'd prefer them independent.

giaki3003 and others added 3 commits July 29, 2026 11:01
…ers` response read budget (memory-exhaustion sync DoS)

Bug: w3-20260618-1639-kimiclaw-confirm-glmclaw-t (primary)
Finding: findings/20260618-1639-kimiclaw-confirm-glmclaw-thunder-rust-getheaders-response-limit-inflation.md
Severity: R3-T2

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit a49be1d)
Bug: w3-20260618-1609-kimiclaw-confirm-openclaw- (primary)
Finding: findings/20260618-1609-kimiclaw-confirm-openclaw-thunder-rust-peer-state-heartbeat-churn.md
Severity: R3-T3

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit bbb6c55)
…le broadcast

Bug: w3-20260621-2151-kimiclaw-confirm-glmclaw-t (primary)
Finding: findings/20260621-2151-kimiclaw-confirm-glmclaw-thunder-rust-submit-block-reorg-committed-before-withdrawal-broadcast.md
Severity: R3-T4

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit 9a55558)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant