fix(wallet): retry flaky Fuji RPC calls - #95
Conversation
Fuji's public RPC intermittently returns HTTP errors / rate limits, which surfaced as 'HTTP request failed' mid-shield and stalled balance reads. Give the eERC viem clients retryCount 5 + a 25s timeout so transient RPC failures self-heal instead of failing the flow.
📝 WalkthroughWalkthroughRPC transport configuration now applies retry and timeout settings to public and wallet clients, including the memoized public client rebuild path. Tests verify the configured retry count. ChangesRPC transport resilience
Estimated code review effort: 2 (Simple) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/wallet/src/lib/eerc.ts`:
- Around line 81-85: Update the existing mocks.http expectation in the
transferPublicUsdc test to include the retryCount, retryDelay, and timeout
options now passed by the publicClient and walletClient transports, while
preserving the expected RPC URL and both client setup calls.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 50d0861b-2845-4aa5-92a6-ccca0fe90f97
📒 Files selected for processing (1)
apps/wallet/src/lib/eerc.ts
| publicClient: createPublicClient({ chain: ACTIVE_CHAIN, transport: http(RPC_URL, { retryCount: 5, retryDelay: 800, timeout: 25_000 }) }), | ||
| walletClient: createWalletClient({ | ||
| account: viemAccount, | ||
| chain: ACTIVE_CHAIN, | ||
| transport: http(RPC_URL), | ||
| transport: http(RPC_URL, { retryCount: 5, retryDelay: 800, timeout: 25_000 }), |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Update the existing http mock expectation.
Lines 81-85 now pass transport options, but apps/wallet/src/lib/eerc.test.ts still expects mocks.http to be called with only "https://rpc.example". The transferPublicUsdc test will therefore fail.
- expect(mocks.http).toHaveBeenCalledWith("https://rpc.example");
+ expect(mocks.http).toHaveBeenCalledWith("https://rpc.example", {
+ retryCount: 5,
+ retryDelay: 800,
+ timeout: 25_000,
+ });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/wallet/src/lib/eerc.ts` around lines 81 - 85, Update the existing
mocks.http expectation in the transferPublicUsdc test to include the retryCount,
retryDelay, and timeout options now passed by the publicClient and walletClient
transports, while preserving the expected RPC URL and both client setup calls.
Fuji's public RPC intermittently returns HTTP errors / rate limits, surfacing as 'HTTP request failed' mid-shield and stalled balance reads. Give the eERC viem clients retryCount 5 + a 25s timeout so transient RPC failures self-heal instead of failing the flow.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/wallet/src/lib/eerc.test.ts (1)
60-60: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winAssert the complete transport configuration.
This expectation only protects
retryCount;retryDelay: 800andtimeout: 25_000fromapps/wallet/src/lib/eerc.ts:78-87andapps/wallet/src/lib/eerc.ts:94-102could regress without failing the test.Suggested assertion
- expect(mocks.http).toHaveBeenCalledWith("https://rpc.example", expect.objectContaining({ retryCount: 5 })); + expect(mocks.http).toHaveBeenCalledWith( + "https://rpc.example", + expect.objectContaining({ retryCount: 5, retryDelay: 800, timeout: 25_000 }), + );🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/wallet/src/lib/eerc.test.ts` at line 60, Update the HTTP mock assertion in the eerc test to verify the complete transport configuration, including retryCount 5, retryDelay 800, and timeout 25_000, while preserving the existing RPC URL check.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@apps/wallet/src/lib/eerc.test.ts`:
- Line 60: Update the HTTP mock assertion in the eerc test to verify the
complete transport configuration, including retryCount 5, retryDelay 800, and
timeout 25_000, while preserving the existing RPC URL check.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 0ca4fa2a-da08-494e-82e4-3b412de8ee4a
📒 Files selected for processing (1)
apps/wallet/src/lib/eerc.test.ts
Fuji's public RPC intermittently fails ('HTTP request failed', rate limits). Give the eERC clients retryCount 5 + 25s timeout so transient failures self-heal. Build ✓ · lint ✓.
Summary by CodeRabbit
Greptile Summary
This PR improves Fuji RPC reliability for wallet eERC calls. The main changes are:
Confidence Score: 5/5
This looks safe to merge.
Important Files Changed
Reviews (2): Last reviewed commit: "fix(wallet): retry flaky Fuji RPC calls ..." | Re-trigger Greptile