v0.11.8
Timeouts on stalled upstreams
An upstream that accepted a connection and then went silent could hang a request indefinitely — several outbound HTTP clients had no read or overall deadline.
- Every outbound client now has a timeout. Hotblocks, remote dataset config, and worker storage requests are bounded, so a stalled upstream surfaces as an error instead of hanging. Streaming responses use an idle timeout, so a healthy stream drained slowly by the client is never truncated. (#130)
- The hotblocks deadline is configurable and lands ahead of the caller's. Its default now sits below the SDK's own request timeout, so a stalled upstream surfaces as a retryable
502from the portal instead of an opaque client-side timeout with nothing recorded on the portal to diagnose. (#133) - A malformed
x-request-idno longer kills the connection. Non-ASCII bytes are valid in an HTTP header value but panicked the request task; such values now fall back to an empty id.
Full Changelog: v0.11.7...v0.11.8