feat: genesis in config API and metrics

[sveitser]

No description provided.

[gemini-code-assist]

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 the 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 counterproductive. 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.

[claude]

Claude finished @sveitser's task in 2m 36s —— View job

---

Code Review: feat: genesis in config API and metrics

• Read repository guidelines (CLAUDE.md)
• Read existing review comments
• Analyze PR diff and changed files
• Provide detailed review feedback

---

Overall: This PR looks good. Clean, well-scoped change that adds genesis visibility in two complementary ways — Prometheus metrics and the config API. The implementation follows existing patterns closely and has solid test coverage.

Summary

The PR exposes genesis configuration through:

1. Metrics (lib.rs): Two new metric families — consensus_genesis (with base_version, upgrade_version, genesis_version labels) and consensus_genesis_upgrade (one gauge per upgrade version). Follows the exact same text_family pattern used for the existing version and build_info metrics.
2. Config API (options.rs): Adds the full Genesis struct to PublicNodeConfig, making it available at /config/runtime. The API doc in config.toml is updated accordingly.

What works well

• Consistent patterns: The metrics registration mirrors the existing version/build_info/node_identity metrics code. The PublicNodeConfig extension follows the existing field-by-field approach.
• Good test coverage: Both metrics assertions (checking exact Prometheus text output) and config API assertions (checking JSON structure) are added to the integration test. The snapshot test is updated. The test_genesis() helper in options.rs keeps unit tests self-contained.
• Security: Genesis contains only public configuration (chain config, versions, stake table capacity, fee accounts/amounts, upgrade definitions) — no private keys or secrets. The existing !key.contains("private") assertion still passes, confirming no secret leakage.
• No ownership issues: PublicNodeConfig::new takes &Genesis and clones, leaving the original available for the subsequent run_with_storage call that takes ownership.

Minor observations

I left two inline comments:

1. Response size (options.rs:693): The accounts field could be large in production. Not a blocker — just worth keeping in mind if the config endpoint response size becomes a concern later.
2. Missing trailing newline (config.toml:14): Pre-existing, but easy to fix while touching the line.

No correctness issues found.

[claude]

nit: The Genesis struct includes accounts: HashMap<FeeAccount, FeeAmount>, which in production genesis files could be a sizable map. Since this is public configuration data (all nodes share the same genesis), there's no security concern, but it may make the /config/runtime response notably larger on chains with many pre-funded accounts. Worth considering whether the accounts map should be excluded or summarized (e.g. just the count) if response size becomes an issue — but fine for now as an observability improvement.

[sveitser]

i think it's always empty, not sure what we have it for even

[claude]

nit: Missing trailing newline — this file still doesn't end with \n. Not introduced by this PR (it was already missing), but easy to fix while you're touching this line.

Suggested change

	DOC = "Get the merged runtime configuration of the current node (CLI flags + env vars + defaults). Secrets and L1 RPC URLs are redacted; only counts (l1_provider_count, l1_ws_provider_count) are exposed. The response includes the resolved genesis configuration (parsed genesis TOML) under the `genesis` field."
	DOC = "Get the merged runtime configuration of the current node (CLI flags + env vars + defaults). Secrets and L1 RPC URLs are redacted; only counts (l1_provider_count, l1_ws_provider_count) are exposed. The response includes the resolved genesis configuration (parsed genesis TOML) under the `genesis` field."

[github-actions]

Nextest failures (1) in this run

Test	Attempts	Time (s)	Main history
hotshot-testing::tests_2::tests_2::catchup::test_all_restart::testtypesrandomizedleader_::pushcdnimpl_::test_all_restart	1	23.63	passing

See the step summary for flaky tests and slowest tests.

[github-actions]

Successfully created backport PR for release-mainnet-1.2.0-rc:

• [Backport release-mainnet-1.2.0-rc] feat: genesis in config API and metrics #4627