Retry SDK indexing on transient timeout before failing

[thedavidmeister]

Depends on #2327.

Problem

Timed-out indexing promises for deposit / withdraw / order transactions surfaced as a hard failure on the very first timeout, even though the timeout is transient (the subgraph just hasn't indexed the tx yet). This produced spurious "failed" toasts for transactions that actually succeeded on-chain.

Change (TS / ui-components only)

createSdkIndexingFn in packages/ui-components/src/lib/providers/transactions/TransactionManager.ts now retries the SDK indexing call up to DEFAULT_MAX_RETRIES (3) total attempts on a timeout result, using the existing retry() backoff, before marking the transaction failed with SUBGRAPH_TIMEOUT_ERROR. This covers every flow routed through createSdkIndexingFn: deposit, withdraw, vaults-withdraw-all, add-order, remove-order, and take-order.

Only timeouts are retried. A successful result, a non-timeout hard error result, and a rejection thrown by the SDK call itself are all surfaced after a single attempt (unchanged fail-fast behavior).

A retry() util (mirroring the one in packages/webapp/src/lib/retry.ts) is added to ui-components because TransactionManager lives in ui-components and cannot import from webapp (webapp depends on ui-components, not the reverse).

Tests (all discriminating — verified to fail against the pre-change code)

New createSdkIndexingFn > timeout retry behavior block plus updated existing timeout tests:

• retries exactly 3 times on a persistent timeout, then SUBGRAPH_TIMEOUT_ERROR + onError (catches no-retry: 1 call).
• recovers and succeeds (SUCCESS + onSuccess, no error state) when a retry after a timeout returns valid data (catches no-retry: fails on first timeout).
• does NOT retry a non-timeout hard error (exactly 1 call) — guards against over-retrying.
• does NOT retry a thrown SDK rejection (exactly 1 call) — guards against over-retrying.
• The two integration-level should handle SDK timeout error in awaitIndexingFn tests (remove-order, deposit) were updated to a persistent-timeout mock + toHaveBeenCalledTimes(3), reflecting the new retry behavior.

Reverting only the source change makes exactly these 4 retry assertions fail, confirming they discriminate.

Verification

• TransactionManager.test.ts: 55/55 pass (39ms under fake timers, no real backoff waits).
• Full @rainlanguage/ui-components suite: 634 tests pass / 100 test files pass. The 2 failing test files (CodeMirrorDotrain.test.ts, License.test.ts) are pre-existing, environment-caused (Failed to resolve entry for package "@rainlanguage/ui-components" — the package self-entry is built by CI's npm run build -w @rainlanguage/ui-components); confirmed identical on clean main with my changes stashed.
• Lint (prettier --list-different + eslint): clean. Prettier format: no changes.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 37 minutes and 10 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

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, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 3cab98d2-8392-4324-9956-453f7407ea16

📥 Commits

Reviewing files that changed from the base of the PR and between f887bca and 9f88f3a.

📒 Files selected for processing (3)

• packages/ui-components/src/__tests__/TransactionManager.test.ts
• packages/ui-components/src/lib/providers/transactions/TransactionManager.ts
• packages/ui-components/src/lib/utils/retry.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 2026-06-13-issue-2327

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[thedavidmeister]

To be clear on disposition: this PR is not being discarded — the retry/backoff mechanic and its tests are sound. It's blocked by #2327, which has been re-scoped to add a typed timeout discriminant (error.kind/code) to the SDK.

The only part of this PR that changes once #2327 lands is the detection: isTimeoutResult (and the SUBGRAPH_TIMEOUT_ERROR labeling) branch on the typed field instead of substring-matching readableMsg. Until that swap the current substring detection shouldn't merge as-is (that's the standing review reject) — but the PR stays open as the retry implementation waiting on its dependency. The reject clears when #2327 lands and this PR adopts the typed signal.