Skip to content

Add test for when batched pegout exceed max tx size - #492

Draft
julia-zack wants to merge 3 commits into
mtmu-ritsfrom
feat/add-pegout-batching-split-test
Draft

Add test for when batched pegout exceed max tx size#492
julia-zack wants to merge 3 commits into
mtmu-ritsfrom
feat/add-pegout-batching-split-test

Conversation

@julia-zack

@julia-zack julia-zack commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

rskj:mtmu-integration

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_ALLOWED into 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.amount is logged per split (not total),
    • each resulting BTC tx virtualSize() is within MAX_STANDARD_TX_SIZE_ALLOWED.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 triggerRelease once. triggerRelease advances to the next pegout creation height a single time (via increaseBlockToNextPegoutHeight) 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 about expectedBatchPegoutTxs = 2 and the final empty pegoutRequests queue 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);

@julia-zack
julia-zack force-pushed the feat/add-pegout-batching-split-test branch from 98fc403 to 953eab1 Compare August 14, 2026 23:51
@julia-zack
julia-zack force-pushed the feat/add-pegout-batching-split-test branch from 953eab1 to 15fcd59 Compare August 20, 2026 20:21
@julia-zack
julia-zack force-pushed the feat/add-pegout-batching-split-test branch from 15fcd59 to 6644e4e Compare August 20, 2026 20:22
@julia-zack
julia-zack force-pushed the feat/add-pegout-batching-split-test branch from 19d1217 to f9ffb1d Compare August 21, 2026 17:31
@sonarqubecloud

Copy link
Copy Markdown

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.

2 participants