feat: add getNodeVersionV2 endpoint#8772
Merged
Conversation
Contributor
Summary of ChangesHello @nflaig, I'm Gemini Code Assist1! 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 API by adding a new endpoint that provides detailed, structured version information for both the beacon node and its associated execution client. This standardization aligns with the Ethereum Engine API, making it easier to identify the specific client implementations and their versions, which is crucial for network diagnostics and compatibility checks. Highlights
🧠 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 AssistThe 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
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 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
The pull request introduces a new getNodeVersionV2 endpoint, providing structured version information for both the beacon node and its execution client. This change centralizes the ClientCode enum and ClientVersion type definitions in packages/api/src/beacon/routes/node.ts, which are then re-exported and used across the codebase. The implementation correctly retrieves client versions and includes a robust fallback for unknown execution clients. Test data for the new endpoint has also been added, ensuring proper functionality. The changes are well-structured and improve consistency by consolidating type definitions.
Contributor
Performance Report✔️ no performance regression detected Full benchmark results
|
Member
Author
|
@lodekeeper please verify the changes in this PR and make sure it's up to date with ethereum/beacon-APIs#568 |
lodekeeper
approved these changes
Feb 3, 2026
Contributor
lodekeeper
left a comment
lodekeeper
left a comment
There was a problem hiding this comment.
LGTM! Verified implementation matches beacon-APIs PR #568:
- ✅ ClientCode enum has all 14 codes per spec (BU, EJ, EG, GE, GR, LH, LS, NM, NB, TE, TK, PM, RH, XX)
- ✅ ClientVersion type has required fields (code, name, version, commit)
- ✅ Response structure correct with snake_case conversion via JsonOnlyResponseCodec
- ✅ Falls back to XX/Unknown when EL client version unavailable
Member
Author
|
waiting for spec discussions to resolve |
Member
Author
|
/gemini review |
Contributor
There was a problem hiding this comment.
Code Review
This pull request successfully introduces the getNodeVersionV2 endpoint, aligning with the updated Ethereum beacon-APIs specification. The changes are well-structured, including the necessary type definitions, endpoint registration, and implementation. A notable improvement is the refactoring that centralizes the ClientVersion and ClientCode definitions, which enhances maintainability by reducing code duplication. The overall implementation is solid, and I have just one minor suggestion to improve code conciseness.
Member
Author
discussion has resolved and the PR is up to date with the spec |
Contributor
|
Verified against beacon-APIs PR #568 — the implementation aligns with the spec: Spec compliance ✅
Implementation notes
Looks good to me 👍 |
Member
Author
|
@lodekeeper please take a look at the latest spec changes and update our implementation to be spec compliant, open a PR against this branch |
## Description Updates the `getNodeVersionV2` endpoint to match the latest [beacon-APIs spec (PR #568)](ethereum/beacon-APIs#568), which changed `execution_client` from a single `ClientVersionV1` to an **array** of `ClientVersionV1`. This supports multiplexed EL connections where `engine_getClientVersionV1` may return multiple entries. ### Changes - `NodeVersionV2.executionClient` → `ClientVersion[]` (optional array) - `IExecutionEngine.clientVersion` → `clientVersions` (stores full array from Engine API) - Graffiti uses `clientVersions?.[0]` for the default graffiti string - Test data updated to match new array type ### Spec Reference From `apis/node/version.v2.yaml`: ```yaml execution_client: type: array items: $ref: '../../beacon-node-oapi.yaml#/components/schemas/ClientVersionV1' ``` > The `execution_client` field is an array because the Engine API's `engine_getClientVersionV1` may return multiple entries when using multiplexed connections. --- *This PR was authored with AI assistance (Claude/Lodekeeper 🌟)* --------- Co-authored-by: lodekeeper <lodekeeper@users.noreply.github.com>
…ent (#8891) ## Description Aligns `getNodeVersionV2` with the latest spec change in [ethereum/beacon-APIs#568](ethereum/beacon-APIs#568). The spec [reverted `execution_client` from an array to a single optional object](eth2353/beacon-APIs@938aa33d) — if the Engine API returns multiple values, the beacon node should return only the first one for consistent behavior across clients. ### Changes - `NodeVersionV2.executionClient`: `ClientVersion[]` → `ClientVersion` (optional singular) - Updated implementation to return single object instead of wrapping in array - Updated test data ### Type of change - [x] Bug fix (non-breaking) ### Checklist - [x] Types compile (`pnpm build` passes) - [x] Unit tests pass (`pnpm --filter @lodestar/api test:unit` — 611/611) _This PR was created with AI assistance (Lodekeeper 🌟)_ Co-authored-by: lodekeeper <lodekeeper@users.noreply.github.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e7522d303f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
ensi321
reviewed
Feb 12, 2026
| data: { | ||
| beaconNode: toSpecClientVersion(getLodestarClientVersion(opts)), | ||
| executionClient: | ||
| chain.executionEngine.clientVersion != null |
Contributor
There was a problem hiding this comment.
If execution client code is XX, we shouldn't include the executionClient field in the response.
I think we should still include XX in the block graffiti on the other hand
Contributor
There was a problem hiding this comment.
Makes sense to me — if the code is XX we essentially don't know the execution client, so omitting executionClient from the response is cleaner than returning unknown values. The spec leaves executionClient as optional for this reason.
We could filter it like:
executionClient:
chain.executionEngine.clientVersion != null && chain.executionEngine.clientVersion.code !== ClientCode.XX
? toSpecClientVersion(chain.executionEngine.clientVersion)
: undefined,Agree on keeping XX in the graffiti though — better to signal that an EL is connected but unidentified than to omit it entirely from blocks.
Member
Author
There was a problem hiding this comment.
was debating that too, I think it's fine either way as the spec just states
Version information about the execution client may not be available
at all times and is therefore optional.
in our case, it's available but it's just a EL we don't know yet, but in practice there isn't much of a difference and returning XX is also not defined in the spec
updated in feebf54
Member
There was a problem hiding this comment.
I agree not returning XX is the right way to go
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## unstable #8772 +/- ##
============================================
- Coverage 52.34% 52.34% -0.01%
============================================
Files 848 848
Lines 63471 63456 -15
Branches 4704 4703 -1
============================================
- Hits 33227 33213 -14
+ Misses 30175 30174 -1
Partials 69 69 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See ethereum/beacon-APIs#568