Conversation
- GovernorBase caches the timelock delay and shares one in-flight fetch across concurrent callers, replacing per-client cache boilerplate - getProposalStatus falls back to the indexed status on RPC failures (e.g. eRPC 429s) instead of failing the request with a 500 - errorHandler logs the error cause (viem shortMessage) instead of a bare "unhandled error" - eRPC api-limit budget gets waitTime: 5s so per-IP bursts queue instead of being rejected with 429/-32005 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
fix(api): dedupe timelock delay reads and survive RPC rate limits
chore: version packages
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1575b90764
ℹ️ 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".
| protected async fetchTimelockDelay(): Promise<bigint> { | ||
| return (await this.readContract({ | ||
| abi: this.abi, | ||
| address: this.address, | ||
| functionName: "EXECUTION_DELAY", | ||
| })) as bigint; |
There was a problem hiding this comment.
Apply the RPC fallback to TORN's status override
For a TORN proposal whose voting period has ended, TORNClient.getProposalStatus bypasses the new base implementation and still awaits getQuorum, getTimelockDelay, and getExecutionExpiration without catching failures. If any of those RPC reads is rate-limited, status hydration in onchainProposals.ts still rejects and the endpoint returns 500 rather than the indexed status, so this DAO does not receive the fallback introduced by this commit.
Useful? React with 👍 / 👎.
| { | ||
| "name": "@anticapture/api", | ||
| "version": "1.5.4", | ||
| "version": "1.5.5", |
There was a problem hiding this comment.
Use a changeset instead of directly bumping the API version
The root AGENTS.md requires every PR to dev to include a changeset (or an empty one) and explicitly says that Changesets owns package versions and changelogs. This commit bumps @anticapture/api and edits its changelog without adding or consuming any .changeset file relative to its parent, bypassing the documented release flow and causing the repository's changeset check to reject the change.
Useful? React with 👍 / 👎.
Note
Medium Risk
Proposal status may be slightly stale when RPC fails (indexed fallback), which affects governance UX but avoids outages; timelock caching behavior changed from per-client to shared base logic.
Overview
Reduces RPC pressure and hard failures when serving live proposal status across many DAO governor clients.
GovernorBase now owns timelock delay caching: DAOs implement
fetchTimelockDelay()(uncached reads) whilegetTimelockDelay()caches the result and dedupes concurrent in-flight fetches—important whengetProposalStatusruns per proposal on list endpoints.getProposalStatuscatches RPC errors (e.g. rate limits) on timelock/grace and quorum reads and returns the indexed DB status with a warn log instead of failing the whole request with 500.The global error handler includes viem’s
shortMessagein unhandled-error log lines. eRPCapi-limitbudgets in dev/prod gainwaitTime: 5sso throttled clients wait briefly instead of failing immediately. API 1.5.5 with a unit test for concurrent timelock dedupe.Reviewed by Cursor Bugbot for commit 1575b90. Configure here.