fix: source the round on-chain in the pending-stake endpoint#736
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 19 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ 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 |
There was a problem hiding this comment.
Pull request overview
This PR updates the /api/pending-stake/[address] endpoint to source currentRound directly from the on-chain RoundsManager (via l2PublicClient) instead of from the subgraph, preventing stale/failed subgraph reads from understating pending stake/fees or causing 500s.
Changes:
- Replace subgraph-backed
getCurrentRound()usage in/api/pending-stake/[address]with an on-chainRoundsManager.currentRound()contract read. - Fetch
BondingManagerandRoundsManageraddresses in parallel via the Controller lookup helpers. - Remove the now-unused
getCurrentRound()helper fromlib/api/ssr.ts.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| pages/api/pending-stake/[address].tsx | Reads currentRound from RoundsManager on-chain and uses it for pendingStake/pendingFees calls, removing subgraph dependency. |
| lib/api/ssr.ts | Removes the unused getCurrentRound() Apollo helper after the endpoint migration. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
/api/pending-stake read the current round from the subgraph and passed it to on-chain pendingStake/pendingFees calls. When indexing falls behind, the stale round understates both values, and a subgraph error or empty response threw "No current round found" and returned a 500. Read currentRound from the RoundsManager via l2PublicClient instead, so the route is a pure contract read that no longer depends on subgraph health. Response shape is unchanged. This was the last caller of the subgraph-backed getCurrentRound() helper, so drop it. queries/currentRound.graphql stays in use by getOrchestrators(). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
c1083e6 to
daa216f
Compare
…r#736) /api/pending-stake read the current round from the subgraph and passed it to on-chain pendingStake/pendingFees calls. When indexing falls behind, the stale round understates both values, and a subgraph error or empty response threw "No current round found" and returned a 500. Read currentRound from the RoundsManager via l2PublicClient instead, so the route is a pure contract read that no longer depends on subgraph health. Response shape is unchanged. This was the last caller of the subgraph-backed getCurrentRound() helper, so drop it. queries/currentRound.graphql stays in use by getOrchestrators(). Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
…r#736) /api/pending-stake read the current round from the subgraph and passed it to on-chain pendingStake/pendingFees calls. When indexing falls behind, the stale round understates both values, and a subgraph error or empty response threw "No current round found" and returned a 500. Read currentRound from the RoundsManager via l2PublicClient instead, so the route is a pure contract read that no longer depends on subgraph health. Response shape is unchanged. This was the last caller of the subgraph-backed getCurrentRound() helper, so drop it. queries/currentRound.graphql stays in use by getOrchestrators().
Follow-up to #731, which moved
/api/current-roundon-chain but left/api/pending-stakeon the subgraph.Problem
/api/pending-stake/[address]read the current round from the subgraph and passed it straight into on-chainpendingStake/pendingFeescalls:layouts/main.tsx) and the staking widget;No current round foundand the route returned a 500.Fix
Read
currentRoundfrom the RoundsManager throughl2PublicClient, in parallel with the BondingManager address lookup. The route becomes a pure contract read that cannot fail on subgraph health. Response shape is unchanged.This was the last caller of the subgraph-backed
getCurrentRound()helper, so it is removed.queries/currentRound.graphqlstays —getOrchestrators()still usesCurrentRoundDocument.Notes
getContractAddressis not memoized, so this route now performs two controller reads instead of one. They run in parallel, so there is no added latency, and it replaces a subgraph HTTP query with an RPC read.