timed out promises will cause such errors in the gut, probably we can setup a retry logic so that such errors are resolved and occurs less often
Updated scope (2026-06-18): detect the timeout via a TYPED error discriminant, not the message text
The retry mechanic itself is simple — retry the SDK indexing call a few times on a transient timeout before surfacing a hard failure. What this issue now requires is that a "timeout" be detected from a typed/structured error signal, not from the human-readable message text.
A first attempt — PR #2720 (TS-only) — gated the retry on a substring match of the message:
result.error?.readableMsg?.toLowerCase().includes("timeout")That approach was rejected as fragile:
- Silent false-negative (the dangerous one): if the SDK ever rewords the message ("timed out", "deadline exceeded", "request expired", "no subgraph response", …), detection returns
false, the retry never fires, and this fix silently regresses — with no test catching it, because the tests hardcode the "...timeout..." message string.
- False-positive → over-retry: any unrelated error whose message merely contains "timeout" (e.g. an RPC-timeout config error, a revert reason naming a timeout param) gets retried 3× before the user sees the real failure.
- It couples runtime control-flow to presentation copy and rests on an undocumented Rust↔TS string convention.
Requirement
- The SDK (
@rainlanguage/raindex, i.e. the Rust/wasm bindings) exposes a typed, structured discriminant on a WasmEncodedResult error — an error kind/code enum with an explicit timeout variant (e.g. SubgraphTimeout) — rather than only a human-readable readableMsg.
- The ui-components retry gate (
isTimeoutResult in TransactionManager.ts) and the existing SUBGRAPH_TIMEOUT_ERROR labeling both branch on that typed field — never on readableMsg text.
- Tests assert against the typed discriminant (ideally pinning that the SDK's real timeout path yields that variant), so a message rewording cannot silently disable the retry.
This is a cross-language change (Rust/wasm error encoding + TS consumption), larger than the TS-only #2720. The retry/backoff mechanics from #2720 can be reused as-is — only the detection must move from prose-matching to a typed signal.
timed out promises will cause such errors in the gut, probably we can setup a retry logic so that such errors are resolved and occurs less often
Updated scope (2026-06-18): detect the timeout via a TYPED error discriminant, not the message text
The retry mechanic itself is simple — retry the SDK indexing call a few times on a transient timeout before surfacing a hard failure. What this issue now requires is that a "timeout" be detected from a typed/structured error signal, not from the human-readable message text.
A first attempt — PR #2720 (TS-only) — gated the retry on a substring match of the message:
That approach was rejected as fragile:
false, the retry never fires, and this fix silently regresses — with no test catching it, because the tests hardcode the"...timeout..."message string.Requirement
@rainlanguage/raindex, i.e. the Rust/wasm bindings) exposes a typed, structured discriminant on aWasmEncodedResulterror — an errorkind/codeenum with an explicit timeout variant (e.g.SubgraphTimeout) — rather than only a human-readablereadableMsg.isTimeoutResultinTransactionManager.ts) and the existingSUBGRAPH_TIMEOUT_ERRORlabeling both branch on that typed field — never onreadableMsgtext.This is a cross-language change (Rust/wasm error encoding + TS consumption), larger than the TS-only #2720. The retry/backoff mechanics from #2720 can be reused as-is — only the detection must move from prose-matching to a typed signal.