Add test for batch resizing via ErrMessageTooLarge #4183
+288
−5
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This test validates the dynamic batch sizing behavior introduced in commit 05ac6df, which allows DA providers to signal that a message is too large without triggering a fallback to the next writer. When a DA provider returns ErrMessageTooLarge, the batch poster should: 1. Re-query GetMaxMessageSize() to learn the new size limit 2. Rebuild a smaller batch that fits within the limit 3. Post to the SAME DA provider (not fall back to calldata) The test has two phases: - Phase 1: Posts ~10KB batches with initial max size of 10KB - Phase 2: Reduces max size to 5KB mid-stream, verifying that subsequent batches are rebuilt smaller rather than falling back
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #4183 +/- ##
==========================================
+ Coverage 32.69% 34.57% +1.88%
==========================================
Files 476 476
Lines 56785 56785
==========================================
+ Hits 18564 19633 +1069
+ Misses 34986 33673 -1313
- Partials 3235 3479 +244 |
Contributor
❌ 5 Tests Failed:
View the top 3 failed tests by shortest run time
📣 Thoughts on this report? Let Codecov know! | Powered by Codecov |
Member
pmikolajczyk41
left a comment
pmikolajczyk41
left a comment
There was a problem hiding this comment.
if I understand correctly: when the DA writer returns ErrMessageTooLarge, we shouldn't fallback, even if other DA systems (calldata, anytrust) are available - we should just rebuild batches for lower limit; therefore, I think we actually should enable batch poster falling back to e.g. calldata, and ensure that it didn't do so
Comment on lines
1129
to
1131
| // Verify follower synced | ||
| _, err = l2B.Client.BlockNumber(ctx) | ||
| Require(t, err) |
Member
There was a problem hiding this comment.
Q1: how does this ensure that the second node actually synced?
Q2: why don't we have a similar check in the 2nd phase?
Comment on lines
1119
to
1127
| // Create L1 blocks to trigger batch posting | ||
| for i := 0; i < 30; i++ { | ||
| SendWaitTestTransactions(t, ctx, builder.L1.Client, []*types.Transaction{ | ||
| builder.L1Info.PrepareTx("Faucet", "User", 30000, big.NewInt(1e12), nil), | ||
| }) | ||
| } | ||
|
|
||
| // Wait for batch to post | ||
| time.Sleep(time.Second * 2) |
Member
There was a problem hiding this comment.
Comment 1: we can use AdvanceL1 utility instead of a loop here
Comment 2 (covering also the follower node syncing): could we reuse checkBatchPosting method here? I think it would be beneficial for us to have the batch posting check as standardized as possible. If I'm not mistaken, currently checkBatchPosting relies on MaxDelay=0, but maybe we can force posting with builder.L2.ConsensusNode.BatchPoster.MaybePostSequencerBatch(ctx) and some other config flag?
| if payloadSize > 6_000 { | ||
| t.Errorf("Phase 2: CustomDA payload size %d exceeds expected max ~5KB", payloadSize) | ||
| } | ||
| } else if daprovider.IsBrotliMessageHeaderByte(headerByte) { |
Member
There was a problem hiding this comment.
I think we should have just else here and fail in case there's a batch that is not AltDA; here and in the first phase loop
The test for ErrMessageTooLarge batch resizing had several issues identified in code review. This commit addresses them to make the test more robust and better verify the intended behavior. Key changes: - Enable fallback (DisableDapFallbackStoreDataOnChain = false) instead of disabling it, so the test proves the batch poster *chooses* not to fall back when receiving ErrMessageTooLarge, rather than being unable to - Replace manual L1 block advancement loops with AdvanceL1 helper - Use WaitForTx to properly verify follower sync instead of just checking BlockNumber (which only confirms the node is responding) - Add follower sync verification to Phase 2 (was missing) - Fail immediately on any non-CustomDA batch type instead of only tracking brotli batches - Allow one oversized batch in Phase 2 to handle the race condition between changing the max size limit and batches already in flight
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This test validates the dynamic batch sizing behavior introduced in commit 05ac6df, which allows DA providers to signal that a message is too large without triggering a fallback to the next writer.
When a DA provider returns ErrMessageTooLarge, the batch poster should:
The test has two phases:
fixes NIT-4158