GH-686 Limits on rate-pack values

[dnwiebe]

Note

Medium Risk
Introduces a new persisted config value and bumps DB schema to v12 with a migration, which can affect node startup/migrations and rate-pack validation. Remaining changes are primarily test/integration stability tweaks and small refactors/logging.

Overview
Adds rate-pack limits as a first-class persisted setting. Introduces DEFAULT_RATE_PACK_LIMITS/RatePackLimits, stores rate_pack_limits in the DB on init, and bumps CURRENT_SCHEMA_VERSION to 12 with a new migration_11_to_12 inserting the default limits.

Updates configuration plumbing and tests. PersistentConfiguration gains rate_pack_limits() with strict parsing/ordering checks, the daemon’s ConfigDaoNull now supplies a default, and setup-reporting tests update expected rate-pack values (scaled to larger wei-like numbers).

Stability/refactor cleanup. Multinode tests are made less flaky (timeouts/sleeps, different external test host, clearer mismatch diagnostics), Docker network creation now retries, gossip/dot-graph rendering gets minor API/formatting tweaks, and accountant charging/logging is refactored to compute total_charge once and include it in debug output.

^{Written by Cursor Bugbot for commit 53cadb4. This will update automatically on new commits. Configure here.}

[czarte]

I am still uncertain, this will protect the MASQ Foundation network, because if someone want's to set rate-pack below the limit, it is just one change and cargo build away from doing so and network does not even aknowledge this. I woud like to propose: make an debut_handler rule, that if the debuting node is in standard, or originate-only mode, and have rate pack below (or above) the limits, his debut is dropped on the flor

[cursor]

Bug: Regex Capture Error Message Mismatch

The parse_capture function's error message "Internal error: regex needs four captures" is incorrect. The RATE_PACK_LIMIT_FORMAT regex actually has 8 capture groups, not 4. This generic message also makes debugging difficult by not indicating which of the 8 expected fields is missing.

 

[kauri-hero]

Hey @dnwiebe @czarte - I agree with @czarte comments to add this additional checking in the handlers to ensure Nodes don't have rate-packs outside of the defined limits now, and can be done without too much additional work.

This will cover older versions of Node joining network with rates outside the hard-coded limits

[cursor]

Test assertion change may mask behavioral regression

Medium Severity

The test debut_target_does_not_introduce_already_known_neighbors had its expected assertion changed from expecting [subject_key, one_common_neighbor_key, another_common_neighbor_key] to expecting only [subject_key]. This significantly alters what the test validates. The change was not discussed in PR comments and appears unrelated to the PR's stated purpose of "rate-pack limits". While the new assertion matches the test name better, this could either be fixing an incorrect test or masking a behavioral regression in gossip handling.

 

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

StandardGossipHandler uses default limits instead of configured limits

High Severity

StandardGossipHandler validates rate packs against DEFAULT_RATE_PACK_LIMITS instead of the configured rate_pack_limits from the database. This is inconsistent with DebutHandler and IntroductionHandler, which both use the configured limits. Nodes with rate packs outside configured limits can bypass validation through standard gossip, undermining the PR's core purpose of enforcing rate pack limits on incoming nodes.