chore: bump to nearcore 2.13.2

[github-actions]

Closes #3992

[gilcu3]

@jancionear here we are facing a problem where some of our tests are timing out after the bump, where before it, nearcore 3.13.1 they were fine. Apparently the problem originated in near/nearcore@df8d1a01 which afaik was originally your code. A quick summary of the diff in test performance is:

Test	main	branch	Delta
foreign_chain_tx_validation	26.2s	49.1s	+22.9s
lost_assets	36.5s	67.8s	+31.3s
ckd_verification	21.8s	57.9s	+36.1s
contract_upgrade (case_2)	26.9s	70.3s	+43.4s
key_resharing	79.7s	130.7s	+51.0s
cancellation_of_resharing	72.1s	126.3s	+54.2s

Does that make sense to you? If yes, is this something we need to fix on our side, or on nearcore side?

Claude mentioned the proper fix is:

set network.experimental.network_config_overrides.received_messages_rate_limits on the indexer nodes
  to lift the Block/BlockRequest caps for localnet.

[jancionear]

Huh that's weird. The rate limits should be high enough to allow the network to run at a normal pace, no matter the load. How do these tests work? Do they run at a normal block time? Or are they sped up to finish more quickly? Speeding it up could go cause the message rate to go above the expected limit.

[gilcu3]

Do they run at a normal block time? Or are they sped up to finish more quickly?

Exactly, they are run at a much faster block time than normal

[jancionear]

If the tests export normal metrics you could also try to look at these ones:

near_peer_message_rate_limited_by_type_total
near_peer_message_received_by_type_total
near_peer_message_sent_by_type_total
near_peer_data_received_bytes

And see how they differ between version bumps or between tests and a real node

[jancionear]

Exactly, they are run at a much faster block time than normal

Ah that makes sense.

Yeah in that case you can disable the rate limits using the config option that claude mentioned. But it's better not to do it on the production setup, as it makes the node more DoSable

[gilcu3]

But it's better not to do it on the production setup, as it makes the node more DoSable

Yeah that's the plan, thanks!

[jancionear]

We could probably add a disable_rate_limits option in the config, that would make things easier for you. Right now I think the config requires specifying a separate rate limit for every message type, which will break when we add a new message.

Although that would go in 2.13.3 or a custom patch

[claude]

Pull request overview

Bumps the workspace near-*/nearcore git dependencies and the e2e sandbox binary from tag 2.13.1 to 2.13.2 (a code-red security release, per #3992). The bump pulled in nearcore's per-message inbound rate limiting (near/nearcore@df8d1a01), whose block-paced caps throttle sped-up local chains and roughly doubled several e2e test runtimes; the PR therefore also lifts the Block/OptimisticBlock/BlockRequest caps on both sides of the localnet P2P link (sandbox and MPC-node NEAR config), guarded so production chains keep the upstream defaults.

Changes:

• Cargo.toml + regenerated Cargo.lock: all ten nearcore git deps retagged 2.13.2 (lockfile diff is tag/rev only, no other crate moved).
• DEFAULT_SANDBOX_VERSION bumped to 2.13.2, keeping scripts/check-sandbox-image-version.sh satisfied.
• E2E sandbox now starts with additional_config lifting the three block-paced inbound rate limits.
• New lift_localnet_block_rate_limits() applied in the is_localnet() branch of apply_near_config_patches, plus three unit tests (localnet lifts, non-localnet untouched, sibling overrides preserved).

Reviewed changes

Per-file summary

File	Description
Cargo.toml	nearcore git dependency tags 2.13.1 → 2.13.2
Cargo.lock	Regenerated; only the nearcore source/rev entries change
crates/test-utils/src/lib.rs	DEFAULT_SANDBOX_VERSION → 2.13.2
crates/e2e-tests/src/near_sandbox.rs	Passes additional_config with unlimited Block/OptimisticBlock/BlockRequest buckets to the sandbox
crates/node/src/config/start.rs	Adds lift_localnet_block_rate_limits(), calls it from the localnet branch, adds 3 tests (first use of rstest in this module)

Findings

Blocking (must fix before merge):

• crates/node/src/config/start.rs:150 — the doc comment states this patcher matches update_near_node_config() in start.sh, and that parity claim is now false: deployment/start.sh:43-44's mpc-localnet branch still only sets state_sync_enabled = False. This is not just a comment problem — deployment/Dockerfile-node:21 runs start.sh as CMD, and the mpc-node start path it uses builds StartConfig with near_init: None (crates/node/src/cli.rs:103), so ensure_near_initialized() no-ops and the Rust patch never runs there. The docker localnet fleet therefore keeps the 10/s cap this PR is trying to lift. Either mirror the override in the python patcher:

  if "$MPC_ENV" == "mpc-localnet":
      config['state_sync_enabled'] = False
      unlimited = {'maximum_size': 1000000, 'refill_rate': 1000000, 'initial_size': 1000000}
      network = config.get('network') or {}
      experimental = network.get('experimental') or {}
      overrides = experimental.get('network_config_overrides') or {}
      overrides['received_messages_rate_limits'] = {
          'rate_limits': {k: unlimited for k in ('Block', 'OptimisticBlock', 'BlockRequest')}
      }
      experimental['network_config_overrides'] = overrides
      network['experimental'] = experimental
      config['network'] = network

  or, if the start.sh/Start path is considered dead pending Deprecate the CLI subcommand in favor of  #2334, qualify the parity claim at start.rs:150 so the comment stops asserting something untrue. Per CLAUDE.md, stale doc comments are review-blocking.

Non-blocking (nits, follow-ups, suggestions):

• deployment/localnet/config.json:107 — received_messages_rate_limits is still null on the localnet validator, which plays exactly the sandbox's role (it receives the MPC indexers' BlockRequests and serves blocks; docs/localnet/localnet.md:68 and scripts/launch-localnet.sh:106 copy this file verbatim into ~/.near/mpc-localnet). By the reasoning in the new near_sandbox.rs:30-33 comment, this peer needs the same lift; leaving it out means the manual/docker localnet keeps the throttled catch-up.
• crates/node/src/config/start.rs:56-62 — the lift only lands on a fresh init. An already-initialized localnet home dir goes through migrate_near_config_state_sync, which returns early for localnet (start.rs:182-185), and nodes started via scripts/launch-localnet.sh:160-174 (mpc-node init + mpc-node start) are never patched at all. Anyone reusing ~/.near/mpc-node-* will still see the slow behaviour with no signal why; consider extending the migration for this one field or noting the requirement in the localnet docs.
• crates/node/src/config/start.rs:295-296 — the "~8.3/s a localnet produces them" figure holds for the sandbox's fast block production but not for ChainId::Localnet, whose checked-in config produces a block every 600 ms (deployment/localnet/config.json:117-120, ~1.7/s) — the function covers both arms. Both numbers are also upstream defaults that will silently rot on the next bump; referencing nearcore's default (or Code red: upgrade nearcore dependencies to 2.13.2 #3992) instead of restating the arithmetic would age better.
• crates/node/src/config/start.rs:299-318 vs crates/e2e-tests/src/near_sandbox.rs:34-53 — the same bucket blob and the same three message keys are now duplicated across two crates, one with a named const and one with bare literals. A key rename upstream needs both edited, and only one is covered by a test. crates/test-utils already exists as the shared source of truth for the sandbox version and would be a natural home for a small unlimited_block_rate_limits() -> serde_json::Value helper.
• crates/node/src/config/start.rs:507-529 — the test only asserts refill_rate, but during catch-up the burst allowance (maximum_size) is what actually gets exhausted; a regression that shrank maximum_size back to single digits would still pass. Worth asserting maximum_size too.
• Worth confirming (I could not verify offline whether nearcore merges or replaces the map): if received_messages_rate_limits.rate_limits replaces nearcore's default map rather than merging per key, this override also drops the caps for every other inbound message type on localnet. Acceptable for a local chain, but it makes the "lift only these three" intent misleading and is worth a clause in the comment.
• crates/node/src/config/start.rs:59 and :220-221 — pre-existing, but they say "post-3.13.2" / "the 3.13.2 upgrade" for what is nearcore 2.13.2; the PR that actually ships 2.13.2 is the natural place to correct that.

⚠️ Issues found

[gilcu3]

@claude review

[claude]

Pull request overview

Bumps the workspace near-*/nearcore git dependencies and the e2e sandbox binary from tag 2.13.1 to 2.13.2 (a code-red security release, per #3992). The bump pulled in nearcore’s per-message inbound rate limiting (near/nearcore@df8d1a01), whose block-paced caps throttle sped-up local chains and roughly doubled several test runtimes; the PR therefore also lifts the Block/OptimisticBlock/BlockRequest caps on every localnet peer it controls — the e2e sandbox, the chain-gateway integration-test nodes, and the MPC node’s own NEAR config — guarded so production chains keep the upstream defaults.

Since the previous review round the parity claim at start.rs:149 has been corrected rather than the start.sh patcher extended (a reasonable call given CliCommand::Start is deprecated by #2334), the maximum_size assertion was added to the new test, and docs/localnet/localnet.md gained a note about config re-init. The chain-gateway test nodes are new in this round.

Changes:

• Cargo.toml + regenerated Cargo.lock: all ten nearcore git deps retagged 2.13.2 (only 2.13.1 → 2.13.2 version moves plus some itertools re-pointing).
• DEFAULT_SANDBOX_VERSION bumped to 2.13.2, keeping scripts/check-sandbox-image-version.sh satisfied.
• E2E sandbox starts with additional_config lifting the three block-paced inbound rate limits.
• New lift_localnet_block_rate_limits() applied in the is_localnet() branch of apply_near_config_patches, plus three unit tests.
• LocalNodeBuilder::new() in the chain-gateway integration tests applies the same lift.
• patch_near_config doc comment no longer claims parity with start.sh; localnet docs note that re-init only happens when config.json is absent.

Reviewed changes

Per-file summary

File	Description
Cargo.toml	nearcore git dependency tags 2.13.1 → 2.13.2
Cargo.lock	Regenerated; only nearcore version/source/rev entries plus itertools selection change
crates/test-utils/src/lib.rs	DEFAULT_SANDBOX_VERSION → 2.13.2
crates/e2e-tests/src/near_sandbox.rs	Passes additional_config with unlimited Block/OptimisticBlock/BlockRequest buckets to the sandbox
crates/chain-gateway/tests/common/node.rs	New lift_block_rate_limits() builder step, applied from new()
crates/node/src/config/start.rs	Adds lift_localnet_block_rate_limits(), calls it from the localnet branch, adds 3 tests; corrects the patch_near_config doc comment
docs/localnet/localnet.md	Notes that NEAR init only runs when config.json is absent

Findings

Blocking (must fix before merge):

• docs/localnet/localnet.md:191 — the new advice to "delete the node home when reusing one from an earlier run" is self-defeating as written. The node home is ~/.near/mpc-frodo (docs/localnet/mpc-config.template.toml:1 sets home_dir to $HOME/.near/$MPC_NODE_ID), which is exactly where the "Configure Frodo’s node" step wrote mpc-config.toml (localnet.md:173-175) — and localnet.md:196 passes that file to start-with-config-file two lines below the new sentence. A reader who follows the instruction where it appears deletes the config they are about to launch with. MpcNode::reset_mpc_state (crates/e2e-tests/src/mpc_node.rs:310-323) models the right sequence: wipe, then re-write the config. Suggested rewording:

  On first start, each node will automatically initialize and configure its NEAR
  data directory using the `[near_init]` settings in the TOML config. Re-init only
  happens while the NEAR `config.json` is absent, so when reusing a home directory
  from an earlier run, delete it and re-run the "Configure ...’s node" step above
  (`mpc-config.toml` lives in the same directory) — otherwise the node keeps its
  stale NEAR config.

Non-blocking (nits, follow-ups, suggestions):

• scripts/launch-localnet.sh:160,174 — the scripted localnet is the one local path still left on the throttled config. It runs mpc-node init, which only calls run_near_init with no patching (crates/node/src/cli.rs:227-231), and then mpc-node start, whose StartConfig carries near_init: None (cli.rs:103), so apply_near_config_patches never executes for those nodes. The manual walkthrough in localnet.md is covered because it uses start-with-config-file; the script is not. Worth either switching the script to start-with-config-file or adding the keys next to the existing jq port patch at line 162.
• deployment/localnet/config.json:107 — received_messages_rate_limits is still null on the localnet validator, which plays exactly the sandbox’s role (it serves the MPC indexers’ BlockRequests; docs/localnet/localnet.md:68 and scripts/launch-localnet.sh:106 copy this file verbatim). The new comment at crates/e2e-tests/src/near_sandbox.rs:30 ("The caps apply to incoming messages, so the sandbox must lift them too") is the argument for lifting it here as well; leaving it out makes the treatment of the two equivalent peers inconsistent.
• crates/node/src/config/start.rs:298-321, crates/e2e-tests/src/near_sandbox.rs:34-55, crates/chain-gateway/tests/common/node.rs:90-106 — the same const UNLIMITED: u32 = 1_000_000 bucket and the same three message keys now exist in three crates, and only the mpc-node copy is covered by a test. An upstream key rename, or a fourth throttled message type, needs three coordinated edits with no compiler or test signal on two of them. crates/test-utils is already the shared home for the sandbox version and could host an unlimited_block_rate_limits() -> serde_json::Value helper for at least the two test crates.
• crates/node/src/config/start.rs:149-151 — the corrected doc comment attributes near_init: None to start.sh, but it is the mpc-node start CLI path (CliCommand::Start → cli.rs:103) that sets it; start.sh merely invokes that command and does its own patching in update_near_node_config(). Naming CliCommand::Start (and its TODO(#2334)) would make the claim traceable, and keep it accurate if start.sh is retired before the CLI path is.
• crates/node/src/config/start.rs:59 and :219 — pre-existing, but both say "post-3.13.2" / "the 3.13.2 upgrade" for what is nearcore 2.13.2. The PR that actually ships 2.13.2 is the natural place to correct that.
• Cargo.lock — besides the 45 2.13.1 → 2.13.2 moves, bindgen and both prost-derive copies were re-pointed from itertools 0.14.0/0.13.0 down to 0.10.5. All within their declared ranges and harmless, but it is unrelated churn for a tag bump; worth confirming the lock was refreshed with a targeted cargo update -p rather than a full re-resolve.

⚠️ Issues found

[netrome]

Thanks!

[haiyuechen-nearone]

Should we add a test for localnet to run WITH the true rate limits as well? I feel like rate limit diffs between local and "prod" is quite significant.

[gilcu3]

This is a relatively complicated matter. Afaik the new rate limits are meant to avoid some possible adversarial behaviors, so they shouldn't add a new gap in tests with honest participants (like the ones we have) in any way. The only reason they did affect our tests is that by default these tests are tweaked to make block production go faster.

[haiyuechen-nearone]

🚢