Only show actual destination values once a request succeeds

[ted-palmer]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
relay-sdk-demo	Ready	Preview	Aug 24, 2026 7:58pm

[github-actions]

Claude finished @ted-palmer's task in 2m 14s —— View job

---

Code Review — PR #1112

• Read PR diff and commit history
• Reviewed relayTransaction.ts (getRequestCurrencies) and consumers (SwapSuccessStep, OnrampModal)
• Reviewed TransactionModalRenderer polling change
• Verified the /requests/v3 response status enum against the terminal-status check

---

Code Review — 1 note

The change is correct and well-scoped. I verified the top-level request status for /requests/v3 responses is "refund" | "waiting" | "depositing" | "failure" | "pending" | "submitted" | "success" (packages/sdk/src/types/api.ts:9435), so:

• Gating settledActual on status === 'success' is right — the non-success states (waiting/depositing/pending/submitted) are exactly the in-flight states where route.actual can hold provisional values.
• The terminal-status set {success, failure, refund} is complete — the remaining four are all non-terminal, so polling correctly continues through them.

Consumers (SwapSuccessStep.tsx:85, OnrampModal.tsx:273) handle a quoted-fallback currencyOut fine, and the refund tx display path is unaffected (it keys off outTxs/refundCurrencyData, not currencyOut).

1. NOTE Correctness: polling cap can prevent the final actual value from ever showing on slow fills
   packages/ui/src/components/common/TransactionModal/TransactionModalRenderer.tsx:243 — the pre-existing if (query.state.dataUpdateCount > 10) return 0 guard is evaluated before the new terminal-status check. Since polling now continues (2500ms) through every non-terminal state instead of stopping once a transaction exists, a fill that takes longer than ~10 refetches (~25s) will hit the cap while still pending/submitted, stop polling, and keep displaying the quoted values — the final actual amount never replaces the quote. This is arguably an acceptable trade-off (quoted is safer than provisional), but it means the changeset's claim that the modal "keeps polling the request until it reaches a terminal status" is only true within that ~25s window. Worth confirming that's the intended behavior for slower cross-chain routes; if not, consider raising/removing the cap once a request is confirmed in-flight.

Everything else looks good — comments are clear and evergreen, the changeset is well-written and follows the repo's guidance, and no repo conventions are violated.
• ted/int2-1312-swap-widget-shows-wrong-output-before-request-success

[github-actions]

Claude finished @ted-palmer's task in 30s —— View job

---

📝 Docs Drift Check — No docs impact

This PR does not touch surfaces that require a relayprotocol/relay-docs update.

[greptile-apps]

Greptile Summary

This update defers display of destination actual values until a request succeeds and extends request polling across nonterminal states. However, the transaction modal still stops polling after eleven successful updates even when a request remains pending, so delayed transactions can fail to refresh to their final received values. This should be corrected before merging.

Confidence Score: 4/5

Not safe to merge until nonterminal transaction requests continue polling long enough to retrieve their final settlement values.

A focused executable check directly exercised the polling callback and reproduced the premature stop while the request was still pending.

Files Needing Attention: packages/ui/src/components/common/TransactionModal/TransactionModalRenderer.tsx

T-Rex Logs

What T-Rex did

• T-Rex produced proof for a posted P1 finding and attached supporting artifacts, including the harness script and two logs.
• T-Rex produced an additional proof for the same P1 finding.
• T-Rex validated the transaction polling cutoff contract by running the harness, which showed a no-cutoff baseline through 2500 ms up to update 11 and then indicated the checked-out callback returning 0 while status was still pending.

_{Ran code and verified through T-Rex}

Comments Outside Diff (2)

1. packages/ui/src/components/common/TransactionModal/TransactionModalRenderer.tsx, line 242-258 (link)

   Nonterminal requests stop polling after eleven updates

   The dataUpdateCount > 10 cutoff runs before the status check. A request that remains waiting, depositing, pending, or submitted through its eleventh successful response receives a 0 refetch interval and is not polled again. If it settles afterward, the completion modal can remain on quoted values instead of retrieving the final actual amounts. Continue polling nonterminal requests, and apply any polling cap only after terminal-state handling.

   Artifacts

   
   

   Evidence from the check

   • The focused Node harness extracts the checked-out refetch callback and invokes it with eleven successful pending-request updates; it demonstrates the cutoff behavior.

   Command output from the check

   • The executed baseline variant removes only the cutoff and returns 2500 ms for all eleven pending-request updates, showing polling would continue.

   Command output from the check

   • The executed checked-out callback returns 0 on the eleventh successful pending-request update, proving automatic polling stops before terminal status.

   

   _{Ran code and verified through T-Rex}

2. General comment

   Nonterminal requests stop polling after eleven successful updates

   • Bug
     • At packages/ui/src/components/common/TransactionModal/TransactionModalRenderer.tsx:242-258, a pending request receives a 2500 ms interval for updates 1-10 but receives 0 on successful update 11. Since this occurs before the terminal-status check, the automatic polling path stops while the request remains nonterminal and cannot automatically retrieve later success/final actual values.
   • Cause
     • The unconditional if (query.state.dataUpdateCount > 10) return 0 precedes the nonterminal-status branch.
   • Fix
     • Only apply a polling cap after confirming the request is terminal (while retaining the refund-output exception), or remove the data-update cap for nonterminal statuses.

   _{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "Only show actual destination values once..." | Re-trigger Greptile}