From a79050911e06c74e1eb61dbb23fae633663fae01 Mon Sep 17 00:00:00 2001 From: relay-docs-bot Date: Wed, 10 Jun 2026 09:24:36 +0000 Subject: [PATCH] docs(drift): draft from internal source Requested by @arcticfloyd1984 via /publish-docs-pr --- references/api/changelog.mdx | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/references/api/changelog.mdx b/references/api/changelog.mdx index 3cb3f9c..fe05938 100644 --- a/references/api/changelog.mdx +++ b/references/api/changelog.mdx @@ -3,6 +3,12 @@ title: "API Changelog" description: "Record of breaking changes, deprecations, and notable additions to the Relay API" --- +## 2026-06-10 — Reorged deposit transactions report `failure` on `inTxs[]` + +**Behavior change** — `GET /requests/v2`: when a deposit is detected as reorged out or canonically failed on Base, the matching entry in `data.inTxs[]` now reports `status: "failure"`. Previously the top-level request `status` could flip to `"failure"` while the corresponding `data.inTxs[].status` remained `"success"`, leaving integrators that key their deposit UI off `data.inTxs[0].status` showing a succeeded deposit. Historical rows are not backfilled; the new behavior applies to detections going forward. + +**Added** — `GET /requests/v2`: failed `data.inTxs[]` entries can now include a `metadata.reorg` object with detection context. Fields: `detectedAt` (unix millis), `source` (detector component), `reason` (short code), and optional `details`, `failReason`, `action` (`"fill"` or `"refund"`), `blockNumber`, `blockHash`, `receiptStatus`. The object is only populated when the failure was caught by the reorg/finality path; deposits that fail through other paths are unaffected. + ## 2026-06-05 — Upstream RPC failures no longer reported as `DESTINATION_TX_FAILED` **Behavior change** — `POST /quote/v2`: quote attempts that fail because of a transient upstream RPC error now return `errorCode: "REQUEST_TIMED_OUT"` on timeout or `errorCode: "RPC_HTTP_ERROR"` for other transient RPC failures. Previously these were misclassified as `errorCode: "DESTINATION_TX_FAILED"`, which suggested an on-chain revert and was treated as non-retryable. `DESTINATION_TX_FAILED` is now returned only for genuine destination reverts. Both new codes are retryable — see [Handling Quote Errors](/references/api/api_core_concepts/handling-errors).