Clamp beacon envelope pagination limit

[dazer1234]

Summary

• Caps beacon envelope pagination limits so oversized requests cannot force excessive result windows.

Validation

• Focused local checks from branch creation; branch already pushed to fork.

Bounty: Scottcjn/rustchain-bounties#305
RTC wallet/miner id: eB51DWp1uECrLZRLsE2cnyZUzfRWvzUzaJzkatTpQV9

Implemented with OpenAI Codex assistance.

[github-actions]

Welcome to RustChain! Thanks for your first pull request.

Before we review, please make sure:

• Non-doc PRs have a BCOS-L1 or BCOS-L2 label
• Doc-only PRs are exempt from BCOS tier labels when they only touch docs/**, *.md, or common image/PDF files
• New code files include an SPDX license header
• You've tested your changes against the live node

Bounty tiers: Micro (1-10 RTC) | Standard (20-50) | Major (75-100) | Critical (100-150)

A maintainer will review your PR soon. Thanks for contributing!

[HCIE2054]

LGTM!

[jaxint]

LGTM! Great work on this PR. 🚀

[minyanyi]

Validated this locally against the new regression coverage.

• The route now matches the existing clamp-to-min-1 pagination behavior already used on other list endpoints, so negative limit values no longer leak through to get_recent_envelopes.
• The new test also checks offset=-5 -> 0, which is the other important half of the pagination contract for this endpoint.

Local check:

• python -m pytest node/tests/test_limit_validation.py -q -> 5 passed

LGTM.

[Auren-Innovation]

Code Review: PR #5679

Title: Clamp beacon envelope pagination limit
Review Type: Standard
Recommended Reward: 8 RTC

---

Summary

Adds a lower-bound clamp of 1 to the beacon envelopes pagination limit parameter. Previously, limit was capped at 50 but could be negative (e.g., limit=-1), which would be passed directly to get_recent_envelopes. The fix ensures limit is always at least 1. A corresponding test verifies the clamping behavior for negative limit and offset values.

Critical

None.

Warning

• The except (ValueError, TypeError) fallback on the next line still defaults limit to 50 and offset to 0. If request.args.get("limit", 50) returns a non-numeric string (e.g., ?limit=abc), the exception handler sets limit=50, which is correct. However, if int() succeeds but produces 0 (e.g., ?limit=0), the new max(1, ...) clamp converts it to 1. This is a behavioral change: a limit=0 request previously passed 0 to get_recent_envelopes, and now passes 1. Verify that returning 1 result for limit=0 is the desired behavior versus returning an error or an empty list.
• The offset parameter has max(..., 0) clamping but no upper bound. An extremely large offset (e.g., offset=999999999) will be passed to get_recent_envelopes unmodified. While this is unlikely to cause security issues, it could result in slow queries if the underlying storage does not handle large offsets efficiently.

Suggestion

• The change is one character (min(...) -> max(1, min(...))). Consider applying the same max(1, ...) lower-bound clamp to the other pagination endpoints in this file for consistency (e.g., the pending list endpoint at the same pattern location). The test file already has test_pending_list_clamps_negative_limit but the corresponding production code may not have the max(1, ...) clamp.
• Consider adding a test case for limit=0 to document the expected behavior at the boundary.

Verdict

Approve - The fix is correct and minimal. The lower-bound clamp prevents negative limits from reaching the data layer. The limit=0 edge case behavior change and the missing upper bound on offset are minor concerns that do not block merge.

---

Review by Herr Amano | 2026-05-19
Wallet: herr-amano

[HCIE2054]

LGTM!