You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would expect the agent to be set from the supplied arguments (since it is defined in the type definitions)
I would expect the agent to be propagated to clones of said request
Environment:
OS:
package-name...:
NodeJS:
Additional context
The text was updated successfully, but these errors were encountered:
I'm not really sure if this is the most compatible option given what's supported now on standard Fetch API. Apparently, the way to set an Agent while conforming to that standard, looks like:
Which runs on node >= 20 (and, for this concrete library, by enabling both skipPolyfill and useNodeFetch). For previous versions, the node-fetch shim was used to provide a somewhat compatible contract with the Fetch API.
Given this library tries to provide an abstraction not only over Fetch API, but also with other fetch-look-alike implementations like node-libcurl, I'm not sure how to reconcile those two views. Regardless, to maximize compatibility and stability, sounds like a good idea to keep this issue open, until either a fix or a decision is reached on how something like that can be achieved.
When instantiating a
Request
theagent
option is not set on theRequest
, it can only be set manually on the request object.This introduces the additional issue that the
agent
is not propagated when anotherRequest
is cloned or instantiated from it.To Reproduce Steps to reproduce the behavior:
Expected behavior
I would expect the agent to be set from the supplied arguments (since it is defined in the type definitions)
I would expect the agent to be propagated to clones of said request
Environment:
package-name...
:Additional context
The text was updated successfully, but these errors were encountered: