Add test for when batched pegout exceed max tx size - #492
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new full-execution 2WP integration test to validate Bridge behavior when a batched pegout would exceed the maximum standard BTC transaction size, ensuring the Bridge splits the batch and emits correct per-split events.
Changes:
- Import
MAX_STANDARD_TX_SIZE_ALLOWEDinto the 2WP test suite. - Add a new pegout test that seeds many federation UTXOs, creates multiple pegout requests in one RSK block, triggers release, and asserts:
- the batch is split into multiple BTC transactions,
release_requested.amountis logged per split (not total),- each resulting BTC tx
virtualSize()is withinMAX_STANDARD_TX_SIZE_ALLOWED.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Suppressed comments (1)
lib/tests/2wp.js:2022
- This test’s own Arrange comment states the Bridge creates one BTC transaction per surviving batch across consecutive pegout creation cycles, but the test only calls
triggerReleaseonce.triggerReleaseadvances to the next pegout creation height a single time (viaincreaseBlockToNextPegoutHeight) and then drives that one pegout through confirmation/signing/broadcast, so a second split batch may never be created/broadcast in this test. This can make the assertions aboutexpectedBatchPegoutTxs = 2and the final emptypegoutRequestsqueue fail or become flaky.
Consider looping releases until the bridge queue is drained (or explicitly triggering a second pegout-creation cycle when requests remain) before collecting events and asserting split counts.
await triggerRelease(rskTxHelpers, btcTxHelper);
98fc403 to
953eab1
Compare
953eab1 to
15fcd59
Compare
15fcd59 to
6644e4e
Compare
19d1217 to
f9ffb1d
Compare
|



rskj:mtmu-integration