PE-9132: Fetch Turbo free allowance concurrently during upload prep - #2169
Conversation
…oad prep PE-9132 getFreeAllowance() (added in #2166) was awaited late in each upload-prep method, after the balance and cost round-trips that already run serially. The allowance call is independent — it only needs the wallet — so it was adding an extra sequential Turbo round-trip to every upload-modal open, and doubling the worst-case wait when payment.ardrive.io is unavailable (two 8s timeouts back to back instead of one) before it fails open. Start the future up front in both getUploadPaymentInfoForEntities and getUploadPaymentInfoForUploadPlans and await it where the free status is computed, so it overlaps the balance, size and cost work. Timing only — no value changes; getFreeAllowance is a non-throwing wrapper, so the in-flight future cannot become an unhandled rejection. 733 tests unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PsV2WFHZMGD9DUfX65cxuW
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesUpload payment evaluation
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
|
Visit the preview URL for this PR (updated for commit 224bf97): https://ardrive-web--pr2169-fix-concurrent-turbo-c6bnlv9k.web.app (expires Mon, 03 Aug 2026 03:00:27 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: a224ebaee2f0939e7665e7630e7d3d6cd7d0f8b0 |
Summary
Follow-up to #2166.
getFreeAllowance()(theGET /v1/account/freecall added there) was awaited late in each upload-preparation method, after the balance and cost round-trips that already run serially. But the allowance call is independent — it only needs the wallet address — so it added an extra sequential Turbo round-trip to every upload-modal open, and doubled the worst-case wait whenpayment.ardrive.iois unavailable (two back-to-back 8sArDriveHTTPtimeouts instead of one) before failing open to size-only behavior.Change
Start the future up front in both
getUploadPaymentInfoForEntitiesandgetUploadPaymentInfoForUploadPlans, and await it where the free status is computed — so the allowance fetch overlaps the balance, size, and cost work already happening.Timing only — no value changes.
getFreeAllowanceis a non-throwing wrapper (falls back tounknown), so the in-flight future can't become an unhandled rejection even if an interveningawaitthrows.Effect
Tests
Full suite unchanged — 733 pass. No behavioral assertions change (same calls, same values, same call counts).
🤖 Generated with Claude Code
https://claude.ai/code/session_01PsV2WFHZMGD9DUfX65cxuW
Summary by CodeRabbit