fix: return available light client updates instead of throwing on missing periods

[lodekeeper]

Description

When getLightClientUpdatesByRange is called with a range that extends beyond the current sync committee period (e.g., start_period=1172&count=128 where 1172 is the latest period), it returns a 500 error because Promise.all rejects when any period throws No partialUpdate available.

Per the beacon API spec:

Servers MUST respond with at least the earliest known result within the requested range, and MUST send results in consecutive order (by period).

Changes

getUpdate() — consistent error type:

• Now throws LightClientServerError(RESOURCE_UNAVAILABLE) instead of generic Error, consistent with all other light client server methods (getBootstrap, getCommitteeRoot)

REST API handler (/eth/v1/beacon/light_client/updates):

• Replaces Promise.all with sequential iteration
• Skips leading unavailable periods to find the earliest known result in the range
• Collects consecutive updates until a gap is hit
• Only catches RESOURCE_UNAVAILABLE; unexpected errors are rethrown (no silent swallowing)
• Returns empty array (not 500) if no updates exist in range

P2P req/resp handler (light_client_updates_by_range):

• Stops yielding gracefully on unavailable periods instead of throwing RESOURCE_UNAVAILABLE error response
• Also skips leading gaps, matching the spec semantics

Before

GET /eth/v1/beacon/light_client/updates?start_period=1172&count=2
→ 500: "No partialUpdate available for 1173"

After

GET /eth/v1/beacon/light_client/updates?start_period=1172&count=2
→ 200: [update for period 1172]

Closes #8902

Note

This PR was authored with AI assistance 🤖

[gemini-code-assist]

Summary of Changes

Hello @lodekeeper, 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 enhances the robustness and compliance of the getLightClientUpdatesByRange API endpoint. It addresses a critical bug where requesting light client updates beyond the current sync committee period would result in a server error, preventing clients from receiving any available data. The changes ensure that the API now gracefully handles such requests by returning all consecutive updates found within the requested range, adhering to the beacon API specification for partial results.

Highlights

• API Error Handling: Resolved an issue where the getLightClientUpdatesByRange API endpoint returned a 500 error when the requested range extended beyond available light client updates.
• Light Client Update Retrieval: Modified the update retrieval logic to sequentially fetch updates and return all available consecutive updates, stopping at the first missing period, in compliance with the beacon API specification.
• Error Messaging: Introduced a specific error message 'No light client updates available in requested range' if no updates are found within the specified range.

🧠 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.

Changelog

• packages/beacon-node/src/api/impl/lightclient/index.ts
  • Imported the LightClientUpdate type.
  • Replaced the Promise.all approach with a for loop to sequentially fetch light client updates.
  • Implemented logic to stop collecting updates and break the loop upon encountering the first missing period, ensuring consecutive results.
  • Added a check to throw a descriptive error if no updates are found in the requested range.

Activity

• No human activity has been recorded on this pull request yet.

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 addresses an issue where getLightClientUpdatesByRange would fail if the requested range included periods without available updates. The change replaces Promise.all with a sequential loop to fetch updates, ensuring that available consecutive updates are returned as per the beacon API specification. While this fixes the bug, it introduces a performance degradation by fetching updates sequentially. I've suggested an alternative using Promise.allSettled to maintain parallel fetching while still correctly handling missing updates.

[nflaig]

/gemini review

[gemini-code-assist]

Code Review

The pull request correctly implements the logic to return available light client updates instead of failing on missing periods, adhering to the beacon API specification. The handling of leading gaps and consecutive results is well-implemented in both REST and P2P handlers. The main area for improvement is the performance of the REST API handler, which currently processes database requests sequentially.