feat: implement getEpochInfo RPC method

[jenish-25]

Closes #28.

Implements the standard Solana getEpochInfo method. It's commonly used by wallets/explorers to show epoch progress, and most of the data is already available in the codebase.

Approach

The handler resolves a single ClickHouse context slot and derives every field from that one slot, so the response is a consistent snapshot:

• absoluteSlot, blockHeight, transactionCount reuse the existing resolution paths (latest_slot_cache, latest_block_height_cache.get_or_refresh, clickhouse.get_transaction_count_by_slot).
• epoch, slotIndex, slotsInEpoch are computed from DEFAULT_SLOTS_PER_EPOCH, assuming the default schedule with no warmup — the same assumption the existing getInflationReward code makes.

It accepts the same optional config object as getSlot (commitment + minContextSlot), rejects processed unless the head cache is enabled, applies the minContextSlot check, and forwards ClickHouse query timings via the downstream header like the sibling handlers.

Response shape (no context wrapper):

{
  "absoluteSlot": 0,
  "blockHeight": 0,
  "epoch": 0,
  "slotIndex": 0,
  "slotsInEpoch": 432000,
  "transactionCount": 0
}

Changes

• handlers/blocks.rs: new handle_get_epoch_info.
• handlers/types.rs: EpochInfo response struct (camelCase, nullable transactionCount).
• handlers/mod.rs: dispatch arm + metrics label.
• tests/mod.rs: param-validation / routing / processed-commitment rejection tests + a serialization test for the wire format.
• crates/superbank-rpc/README.md: added to the supported-methods and config-object lists.

Testing

• cargo fmt --all -- --check — clean.
• cargo clippy -p superbank-rpc --all-targets --locked -- -D warnings — clean (default features).
• cargo test -p superbank-rpc --locked — passes (292 tests; 5 new).
• cargo check/tests under --features grpc-head-cache — pass.

Note: the crate's test harness only has an in-memory hook for the latest-slot query, so the added tests cover param validation, routing, commitment handling, and the serialized wire shape rather than an end-to-end value (which needs a live ClickHouse). Happy to extend if there's a preferred pattern for mocking the block-height/transaction-count queries.

Per the issue, this assumes the default epoch schedule (no warmup), consistent with the existing code.

[Mctursh]

lgtm🚀

[jenish-25]

@notwedtm

[notwedtm]

Okay, so I've been reviewing this one a bit deeper because it's continuing a bad pattern that I introduced a while ago.

Basically, getEpochInfo computes its epoch fields with plain integer math — epoch = slot / 432000, slotIndex = slot % 432000, slotsInEpoch = 432000 — which hardcodes the assumption that the cluster uses Solana's default epoch schedule with warmup disabled. That's exactly right for mainnet-beta, but on testnet or any cluster whose genesis enables warmup, the early epochs are short (32, 64, … up to 262,144 slots, with normal 432,000-slot epochs only starting at slot 524,256), so every field the method returns is silently wrong there: at slot 1,000,000 real Solana reports epoch 15, while superbank would report epoch 2 with a slotsInEpoch that never varies.

I think the best approach would be to merge this PR in as-is, and then follow up with another PR to fix these to calculate properly for non-mainnet chains.

[Mctursh]

Yeah, this goes wider than getEpochInfo. I hit the same assumption in getEpochSchedule (#36), which hardcodes the mainnet no-warmup schedule. And getInflationReward on main does it too, in two spots (the default-epoch math and the epoch-to-slot bounds). So it's three methods all assuming mainnet, because the RPC layer has no source for the cluster's real schedule.

The design question before any fix: where should that schedule come from? The ingestor already calls get_epoch_schedule() on its RPC client in the bigtable path, it's just not plumbed through to the RPC layer. A config flag, ingest-and-store, or fetch from upstream at startup all seem viable. Any direction the team's leaning?

I'm close to this through #36, so once there's a direction I can take the follow-up across all three.

[notwedtm]

Yeah, this goes wider than getEpochInfo. I hit the same assumption in getEpochSchedule (#36), which hardcodes the mainnet no-warmup schedule. And getInflationReward on main does it too, in two spots (the default-epoch math and the epoch-to-slot bounds). So it's three methods all assuming mainnet, because the RPC layer has no source for the cluster's real schedule.

The design question before any fix: where should that schedule come from? The ingestor already calls get_epoch_schedule() on its RPC client in the bigtable path, it's just not plumbed through to the RPC layer. A config flag, ingest-and-store, or fetch from upstream at startup all seem viable. Any direction the team's leaning?

I'm close to this through #36, so once there's a direction I can take the follow-up across all three.

Agreed!

I think the ingest-and-store pattern for leader schedule is probably the right approach for Superbank given its goals. Since not all sources expose the schedules (or even have them), we'll need to ensure that any methods that rely on them are under a feature flag.

[Mctursh]

Agreed!

I think the ingest-and-store pattern for leader schedule is probably the right approach for Superbank given its goals. Since not all sources expose the schedules (or even have them), we'll need to ensure that any methods that rely on them are under a feature flag.

Thanks, ingest-and-store works for me. I'll write this up as a tracking issue so the design doesn't clutter this PR, and tag you there. Scoping it to the epoch schedule specifically, since that's what the three methods need and there's no leader-schedule method in the repo yet.