fix: stop fetching request on success modal close

[ted-palmer]

No description provided.

[vercel]

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

Project	Deployment	Actions	Updated
relay-sdk-demo	Ready	Preview	Sep 2, 2026 5:34pm UTC

[github-actions]

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

---

📝 Docs Drift Check — No docs impact

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

[github-actions]

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

---

Code Review

• Gather context (diff, commit, useRequests hook, full file)
• Review for correctness, error handling, architecture, repo guidelines

Code Review — No issues found.

Reviewed 2 files, ~88 lines changed. Checked for correctness, error handling, and repo guidelines compliance.

The fix is correct. Root cause verified against packages/hooks/src/hooks/useRequests.ts: the query filter (options) is only ever { id: requestId }, but the old enabled flag was true whenever requestId || allTxHashes[0]. So in the window where progressStep was Success/Error and tx hashes existed but requestId had been dropped (e.g. steps cleared on close), enabled: true combined with options: undefined fired GET /requests/v3 with no filters. Deriving requestQuery once and setting enabled: Boolean(requestQuery) makes the enabled flag track the actual filter — no fetch fires without an id, and no functionality is lost since the tx-hash branch never contributed a filter anyway.

Other checks:

• refetchInterval logic is preserved verbatim (terminal-status and refund/outTxs polling unchanged).
• Boolean(requestQuery) is consistent with the hook's internal default (enabled: options !== undefined), so the explicit override doesn't diverge.
• Changeset is scoped to @relayprotocol/relay-kit-ui (patch) and clearly states the user-visible effect. Prettier conventions (no semicolons, single quotes) match.

[greptile-apps]

Greptile Summary

The transaction modal now creates and enables terminal request-history polling only when a deposit request ID is available, preventing a broad request lookup after transaction state is cleared.

Confidence Score: 5/5

No blocking failure remains.

No accepted blocking findings remain.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for a posted P1 finding.
• T-Rex built and bundled the lifecycle harness with bun build trex-artifacts/int2-1029-lifecycle-harness.tsx targeting browser, producing trex-artifacts/int2-1029-lifecycle-harness.js and bundling 490 modules.
• The locally served harness responded with HTTP 200, indicating the bundle was served successfully.
• A Playwright run launched Chromium to exercise the page and reported an error: No QueryClient set, with a message to use QueryClientProvider; the run also showed RESULT: MISSING_RESULT and empty hook fetch and network event lists.
• There was no terminal or close request URL observed during the Playwright run.

_{Ran code and verified through T-Rex}

_{Reviews (2): Last reviewed commit: "Merge branch 'main' into ted/int2-1029-r..." | Re-trigger Greptile}

[github-actions]

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

---

📝 Docs Drift Check — No docs impact

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

[github-actions]

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

---

Code Review

• Gather context (diff, commit history, useRequests hook, full renderer)
• Review for correctness, error handling, architecture, repo guidelines

Code Review — No issues found.

Reviewed 2 files, ~88 lines changed. Checked for correctness, security, error handling, and repo guidelines compliance.

The fix is correct. Root cause confirmed against packages/hooks/src/hooks/useRequests.ts: the query options is only ever { id: requestId }, but the old enabled flag was true whenever requestId || allTxHashes[0]. In the window where progressStep was Success/Error with tx hashes present but requestId already dropped (e.g. steps cleared on close), enabled: true combined with options: undefined fired GET /requests/v3 with no filters. Deriving requestQuery once and setting enabled: Boolean(requestQuery) makes the enabled flag track the actual filter — no fetch fires without an id, and nothing is lost since the tx-hash branch never contributed a filter.

Other checks:

• refetchInterval logic is preserved verbatim (terminal-status and refund/outTxs polling unchanged); the diff is just re-indentation from moving the options object out.
• Boolean(requestQuery) is consistent with the hook's own default (enabled: options !== undefined), so the explicit override doesn't diverge from intended behavior.
• Changeset is scoped to @relayprotocol/relay-kit-ui (patch) and states the user-visible effect clearly; prettier conventions (no semicolons, single quotes) are respected.

[greptile-apps]

Request-query lifecycle remains unverified

• Bug
  • The prior INT2-1029 finding is unknown. The attempted rendered browser test did not mount the component because its bundled React Query provider and the real useRequests hook used different query contexts. As a result, the run observed no request URL and did not exercise the Success, Error, or close/clear request-query paths. The changed source builds { id: requestId } only for terminal states and uses enabled: Boolean(requestQuery), but source inspection is not execution proof.
• Cause
  • The verification harness failed before the real useRequests request function could run: No QueryClient set, use QueryClientProvider to set one.
• Fix
  • Run the focused rendered test with a single shared @tanstack/react-query module instance, then assert the real hook's emitted request URLs for Success, Error, and close/clear transitions.

_{Ran code and verified through T-Rex}