Found reviewing @mysten-incubation/memwal@0.1.8-dev.0.
0.1.8-dev.0 adds a deadline to every relayer request — a real improvement over 0.1.7, where only recall carried an abort signal. But the deadline is disposed as soon as the response headers arrive, before the body is read:
// dist/memwal.js:1255
deadline.dispose();
// :1259
await res.text();
// :1282
return res.json();
So a server that returns headers and then stalls mid-body leaves the SDK hanging with no bound at all — the exact failure the deadline was added to prevent, just moved one step later.
This is narrower than the pre-0.1.8 situation, and for the hosted relayer it is unlikely. It matters for a proxied or self-hosted deployment, and it is the kind of stall that reads as "the client hung" rather than as a timeout.
Fix
Keep the deadline armed across the body read — dispose it in a finally after res.text() / res.json() resolves, rather than immediately after fetch returns.
Where
packages/sdk/src/memwal.ts, signedRequest / fetchWithDeadline.
Found reviewing
@mysten-incubation/memwal@0.1.8-dev.0.0.1.8-dev.0adds a deadline to every relayer request — a real improvement over0.1.7, where onlyrecallcarried an abort signal. But the deadline is disposed as soon as the response headers arrive, before the body is read:So a server that returns headers and then stalls mid-body leaves the SDK hanging with no bound at all — the exact failure the deadline was added to prevent, just moved one step later.
This is narrower than the pre-
0.1.8situation, and for the hosted relayer it is unlikely. It matters for a proxied or self-hosted deployment, and it is the kind of stall that reads as "the client hung" rather than as a timeout.Fix
Keep the deadline armed across the body read — dispose it in a
finallyafterres.text()/res.json()resolves, rather than immediately afterfetchreturns.Where
packages/sdk/src/memwal.ts,signedRequest/fetchWithDeadline.