`resetTimeoutOnProgress` on low-level `request()` only works when `onprogress` is explicitly provided

[ContextVM-org]

I found a behavior in the TypeScript SDK that feels surprising when using the low-level request() API.

When I call request() with resetTimeoutOnProgress: true, I would expect incoming progress notifications to keep the request alive for timeout purposes. In practice, that only seems to happen when onprogress is explicitly provided in the request options.

The issue is not that I do not want to track progress. In my case, progress may already be consumed through lower-level transport features. The problem is that if onprogress is not explicitly set on request(), the timeout reset behavior does not seem to activate.

This makes resetTimeoutOnProgress behave more narrowly than its name suggests. It appears to be coupled to explicit callback registration rather than to the presence of valid progress activity for the request.

From my point of view, there are two reasonable outcomes.

One option would be to make resetTimeoutOnProgress work whenever the request is progress-capable and valid progress notifications are received, even if onprogress is not explicitly passed.

The other option would be to document clearly that resetTimeoutOnProgress only has an effect when onprogress is explicitly provided on the same request() call.