Skip to content

feat: mpool msg limits #5732

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 16 commits into from
Jul 7, 2025
Merged

feat: mpool msg limits #5732

merged 16 commits into from
Jul 7, 2025

Conversation

LesnyRumcajs
Copy link
Member

@LesnyRumcajs LesnyRumcajs commented Jun 13, 2025

Summary of changes

Follow up of #5729.

Changes introduced in this pull request:

  • added block message limits (same as in Lotus - 8192 per message type and 10000 globally),
  • migrated some refactoring that was made in the Lotus around adding different message chains,
  • fixed a few random bugs that I uncovered while implementing the above,
  • optimal selection now doesn't fail to pack a block.

Reference issue to close (if applicable)

Closes #5730

Other information and links

Change checklist

  • I have performed a self-review of my own code,
  • I have made corresponding changes to the documentation. All new code adheres to the team's documentation standards,
  • I have added tests that prove my fix is effective or that my feature works (if possible),
  • I have made sure the CHANGELOG is up-to-date. All user-facing changes should be reflected in this document.

@LesnyRumcajs LesnyRumcajs force-pushed the mpoll-msg-limits branch 15 times, most recently from 9091ffe to 39218ff Compare June 18, 2025 17:04
@LesnyRumcajs LesnyRumcajs force-pushed the mpoll-msg-limits branch 3 times, most recently from e4c59ae to 6913987 Compare July 3, 2025 16:02
Comment on lines +16 to +25
# This test checks the limitations of the message pool, which can take a while.
[[profile.default.overrides]]
filter = 'test(message_pool::msgpool::selection::test_selection::message_selection_trimming_msgs_two_senders)'
slow-timeout = { period = "120s", terminate-after = 3 }

# This test checks the limitations of the message pool, which can take a while.
[[profile.default.overrides]]
filter = 'test(message_pool::msgpool::selection::test_selection::message_selection_trimming_msgs_two_senders_complex)'
slow-timeout = { period = "120s", terminate-after = 3 }

Copy link
Member Author

Choose a reason for hiding this comment

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

This could be mitigated by #5812. I'm not certain that's the culprit, but my spidey senses tell me that it's the only reasonable possibility.

@@ -218,7 +226,7 @@ impl Chains {
chain_node.msgs.clear();
chain_node.valid = false;
} else {
chain_node.msgs.drain(0..i as usize + 1);
chain_node.msgs.truncate(i as usize + 1);
Copy link
Member Author

Choose a reason for hiding this comment

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

outstanding bug from 2021 that made on of the new tests fail

@@ -429,7 +439,7 @@ where
let network_version = chain_config.network_version(ts.epoch());

let min_gas = price_list_by_network_version(network_version)
.on_chain_message(to_vec(m)?.len())
.on_chain_message(m.chain_length()?)
Copy link
Member Author

Choose a reason for hiding this comment

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

outstanding bug that made us overcharge for some messages (thus them or others not being selected)

Comment on lines -231 to +234
if to_vec(msg)?.len() > 32 * 1024 {
if to_vec(msg)?.len() > MAX_MESSAGE_SIZE {
Copy link
Member Author

Choose a reason for hiding this comment

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

Lotus allows messages of up to 64 KiB, so should we.

@LesnyRumcajs LesnyRumcajs marked this pull request as ready for review July 4, 2025 10:02
@LesnyRumcajs LesnyRumcajs requested a review from a team as a code owner July 4, 2025 10:02
@LesnyRumcajs LesnyRumcajs requested review from hanabi1224 and akaladarshi and removed request for a team July 4, 2025 10:02
@LesnyRumcajs LesnyRumcajs added the RPC requires calibnet RPC checks to run on CI label Jul 4, 2025 — with Graphite App
@@ -29,6 +33,253 @@ type Pending = HashMap<Address, HashMap<u64, SignedMessage>>;
// A cap on maximum number of message to include in a block
const MAX_BLOCK_MSGS: usize = 16000;
const MAX_BLOCKS: usize = 15;
const CBOR_GEN_LIMIT: usize = 8192; // Same limits as in Go's `cbor-gen`.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you add the link to the go code.

Copy link
Collaborator

@akaladarshi akaladarshi left a comment

Choose a reason for hiding this comment

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

Right now I see we are using two different types anyhow::Result and Result in lot of places, I feel we should use one for consistency. Not sure if this is the correct PR to resolve if at all, Otherwise, LGTM.

@LesnyRumcajs LesnyRumcajs added this pull request to the merge queue Jul 7, 2025
Merged via the queue into main with commit 2a9269e Jul 7, 2025
67 of 71 checks passed
@LesnyRumcajs LesnyRumcajs deleted the mpoll-msg-limits branch July 7, 2025 16:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RPC requires calibnet RPC checks to run on CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Backport block message limit logic in mempool module
3 participants