fix(web): apply the client request timeout instead of dropping it - #722
Merged
Makisuo merged 1 commit intoSep 1, 2026
Merged
Conversation
`mapleFetch` passed `init?.signal ?? AbortSignal.timeout(CLIENT_TIMEOUT_MS)`, but Effect's `FetchHttpClient` supplies its own signal on every request — the fiber's interrupt — so `init.signal` was always set and the 45-second timeout never applied. A stalled API or warehouse request stayed pending indefinitely, holding the query that issued it. The deadline moves to the client layer as `Effect.timeoutOrElse`, rather than being repaired in place by composing two abort signals. A deadline the fetch implementation holds is the wrong shape: timing out the fiber is what aborts the in-flight request, so there is one deadline enforced by the runtime instead of a second signal raced against the runtime's own. It fails as an `HttpClientError` carrying a `TransportError`, which is what consumers already handle. `mapleFetch` reads an abort as evidence of nothing, which is right for an interrupt and wrong for a deadline, so the timeout marks the origin unreachable itself.
Makisuo
force-pushed
the
fix/02-web-client-request-timeout
branch
from
September 1, 2026 14:51
f05d95f to
64c0330
Compare
🍁 Maple PR previewWarning Preview cleanup could not be confirmed. The Alchemy teardown outcome was Final commit |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second of a five-PR stack, based on #721.
mapleFetchpassedinit?.signal ?? AbortSignal.timeout(CLIENT_TIMEOUT_MS). Effect'sFetchHttpClientsupplies its own signal on every request — the fiber's interrupt — soinit.signalwas always set and the 45-second timeout never applied. A stalled API or warehouse request stayed pending indefinitely, holding the query that issued it.The deadline moves to the client layer as
Effect.timeoutOrElse, rather than being repaired in place by composing two abort signals. A deadline the fetch implementation holds is the wrong shape: timing out the fiber is what aborts the in-flight request, so there is one deadline enforced by the runtime instead of a second signal raced against the runtime's own. It fails as anHttpClientErrorcarrying aTransportError, which is what consumers already handle.mapleFetchreads an abort as evidence of nothing, which is right for an interrupt and wrong for a deadline, so the timeout marks the origin unreachable itself.Server-side warehouse attempts are already capped well below 45s, so nothing legitimate runs into this.
Tests
http-client.test.tsdrives the real client over a stubFetchHttpClient.Fetchon theTestClock: still pending at 44s, failed with anHttpClientErrorat 45s, and a responding request untouched.