Uh oh!
There was an error while loading. Please reload this page.
fix(balances): degrade gracefully when staking is unavailable - #389
Conversation
The balances command scans the global validator set (active + quarantined +
banned) to compute delegated committed principal per vesting. Those SDK reads
throw on networks with no staking contract ("Staking is not supported on
studio-based networks"), so `genlayer balances` failed outright on studio —
even though wallet balance and vesting totals need no staking data.
Gate the scan on staking availability, mirroring the SDK's own guard (missing
or zero staking address ⇒ unsupported): when absent, use an empty validator set
so delegated principal is 0 (correct — there is no delegation without staking)
and still render wallet + vesting holdings. Self-stake, vested/withdrawable and
available-to-stake all come from vesting/wallet reads and are unaffected.
Fixes genlayer-cli (studio) e2e 090_cli_network_and_balances #2.Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Uh oh!
There was an error while loading. Please reload this page.
…391) After #389 stopped the staking scan from crashing balances on studio, the next consensus-dependent read surfaced: the vesting-factory lookup resolves through ConsensusMain → AddressManager, and on a network without that infrastructure deployed (studio, or a custom profile on a bare RPC) it decodes garbage — `genlayer balances` died with 'Position 32 is out of bounds ... name()' (e2e 090 scenario 2 on the studio stack). Custom networks inherit the base chain's ConsensusMain address even without a --consensus-main override, so a studio profile carries a non-null (localnet) address that simply isn't deployed on the studio RPC — a static check can't tell them apart. Probe eth_getCode(consensusMain) once up front: if empty, the consensus infra isn't deployed, so skip the whole consensus-dependent section (vesting + staking) and render the wallet balance only, with a clear note. Handles the entire missing-infra class in one capability check rather than one revert at a time. dev-env (real deployed address) is unaffected. Verified against a live studio stack: e2e 090 (both scenarios) green. 772/772 unit tests pass.
What
genlayer balancesscans the global validator set (active + quarantined + banned) to compute each vesting's delegated committed principal. Those SDK reads throw on networks with no staking contract (Staking is not supported on studio-based networks), so the whole command failed on studio — even though wallet balance and vesting totals need no staking data at all.This gates the scan on staking availability, mirroring the SDK's own guard (missing or zero staking address ⇒ unsupported). When staking is unavailable the validator set is empty, so delegated principal is
0(correct — there is no delegation without staking) and the command still renders wallet + vesting holdings. Self-stake, vested/withdrawable and available-to-stake all come from vesting/wallet reads and are unaffected.Why
Surfaced by genlayer-cli (studio) e2e:
090_cli_network_and_balancesscenario 2 ("Read the signer wallet balance through the balances command") failed on studio becausebalanceshit the staking read and exited 1. dev-env (staking present) was unaffected.Test
testnet-bradbury(which has a staking contract) so they still exercise the union/de-dup scan.(a'): onstudionet(no staking contract) the scan is skipped, no staking read is called, no failure, and wallet + vesting + self-stake are still reported with delegated principal 0.Validated end-to-end via genlayer-e2e #653 (Depends-On).