just to make sure it won't fire

they may be, in a retries plugin situation, resent to the coalesced connection, and corrupt it

this avoid needlessly waiting for a socket we haven't yet written to (usually DNS related)

which may happen in fiber scheduler contexts, where selector is shared across fibers

native: create and write dns query to socket as soon as there's payload

See merge request !458

it's actually where it is used

this was introduced alongside a similar handler in http2 which was removed when callbacks were introduced (the plugin), so this seems to have been left behind

only component worth defending against

align with what has already been done for response

all handled errors should be for HTTPX::Error

this fixes an issue with the max headers size or max response nbody size options, which were closing the whole connection and potentially legitimate requests; this way, only the given stream is closed and the error bubbles up only to that request

only dealing with HTTPX::Error here. The reasoning is that we only should deal with the expected, and the main issue from the prior state is that stuff like Timeout.timeout would be caught and handled in these blocks and not bubble up like user code would expect

and on TCPSocket#close, just rescue IOError

since one rescues it immediately afterwards, it's basically control flow logic

webmock: prevent mocked connections from connecting to the peer server (which may now happen with the initial call)

remove StandardError rescuing

See merge request !457

went from 'tid:123, fid:123' to 'tid=123 fid:123'

this will allow log analyzers to more efficiently filter through process logs and extract the relevant information for a given trace

log ids different format + datadog correlation ids

See merge request !459

a bug was introduced during the fiber scheduler integration work for
1.8.0, where touching a connection used across fibers relied on states
being fluid during IO calls. this escalated poorly to when a connection,
on connect timeout, never moves the socket from idle, which is then
interpreted, during the termination as another fiber having picked it
up; and later on, because it's socket is idle, the connection doesn't
transition to closed, which blocks the termination loop of the
selector/session. even more sadly, the existing test for connect timeout
relies on a socket being connectable, timing it out only during the
transition to a tls socket, so the non-routeable case was never covered.

this is now fixed by force-transitioning idle sockets to closed. this
fixes the immediate issue, while keeping the semantics for fiber
schedulers, as this forceful transition happens without any IO op in the
middle. this is made at the expense of bypassing the state machine
transition API, which doesn't please me much.

Closes #387

when in a persistent connection, if the connection is dropped on first
attempt after the keep alive timeout, and because of a connection issue
deemed retriable, the retry after interval is skipped; the reasoning is
that the peer server has dropped the connection meanwhile, and waiting
before retrying is redundant under such a scenario.

this should also help without concurrent requests, where retries won't
look sequential on error.

persistent: skip retry after interval when recovering from keep alive

See merge request !461

fix: transition io to closed on connect timeout to prevent term loop

Closes #387

See merge request !460

auth: when coupled with retries plugin, issue the retry immediately when recovering from a 401 error

on reason for triggering any backoff strategy

alias answers were being cached but not inserted in the LRU hostnames list, causing an infinite loop where no more hostnames were to be found in the LRU and still the lookup list would be full

Closes #388

Richard Peng authored Jul 20, 2026 and Tiago committed Jul 21, 2026

this helps prevent a resource leak when a remote closes a persistent
connection

the previous commit was pointing at the right direction, as in, timers
were left dangling behind when requests were reset for retry. However,
not only they broke the total request timeout logic (which is supposed
to survive request resets), it also kept the timer reference with the
:idle timer (which would be dropped on reset, but isn't on request
completion).

this revamps the request timer clean up logic by making the request
store all request timers, which are then labelled. timers are cleared on
request reset AND request completion, where the total request timeout is
kept around on request reset specifically.

in most cases it should not be an issue, but may be more concerning in fiber scheduler scenarios

an issue is happening where an openssl connection returns
:wait_readable/writable on connect but then returns nil when selected
on, as if it were being closed, and this affects the whole tree.

increased the number of retries so that at least they complete
eventually despite the multiple connect timeout errors.

clear timer callbacks on connection close

See merge request !463

it now reliably supports the case where multiple fibers are waiting on the same IO

it will also not transfer to the same ready fiber multiple times within the same run_once block, which was causing IO#wait calls to return nil immediately and breaking

This reverts commit 58aa9cd1.