rpcserver: enforce max_events limit of 50000 for ForwardingHistory

[EricGrill]

Summary

• Enforces the documented 50k limit on ForwardingHistory responses
• Caps num_max_events at 50000 as stated in the proto documentation

Background

The API documentation states "each response can only contain 50k records" but this limit was not actually enforced. This PR implements the documented behavior.

Test plan

• Verified logic caps events at 50000 when higher values requested
• Default of 100 still works when not specified

Closes #10496

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @EricGrill, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request ensures consistency between the ForwardingHistory API's documented behavior and its actual implementation. It introduces a mechanism to enforce the stated limit of 50,000 records per response, preventing clients from requesting or receiving an excessive number of events in a single call. This change improves API reliability and resource management by adhering to established boundaries.

Highlights

• API Limit Enforcement: The ForwardingHistory RPC now strictly enforces its documented maximum event limit of 50,000 records per response, preventing requests for higher values from exceeding this cap.
• num_max_events Capping: The num_max_events parameter for ForwardingHistory requests is now capped at 50,000, aligning with the protocol documentation.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly enforces the documented 50,000 event limit for ForwardingHistory responses. The implementation is sound, but it introduces a new constant for a limit that is already defined elsewhere. My feedback suggests using the existing channeldb.MaxResponseEvents constant to avoid duplication and improve maintainability.

[gemini-code-assist]

To avoid code duplication, it's better to use the existing channeldb.MaxResponseEvents constant, which is defined for this exact purpose. This ensures the limit is defined in a single place, improving maintainability.

	// Cap at the maximum number of events as documented in the API.
	if numEvents > channeldb.MaxResponseEvents {
		numEvents = channeldb.MaxResponseEvents
	}

[fresh3nough]

Thanks for working on this! I've consolidated your approach with #10512.

The consolidated PR (#10512) now uses the channeldb.MaxResponseEvents constant as you suggested, which avoids code duplication. However, instead of silently capping the value, it returns an error when the limit is exceeded, which provides better feedback to API clients.

The implementation also includes comprehensive unit tests to ensure the validation works correctly across various scenarios.

Feel free to review #10512 and let me know if you have any suggestions!