This would solve...
In a library I am working on, they had 2 events (request & response) that would fire before and after a request was made. The purpose of these events was for analytics (ie. receiving a "weird" response code and checking the body). With undici, I'm hoping that these events can be removed entirely and instead use the diagnostics_channel support (the library only supports v16.9.0+).
The implementation should look like...
In the request property, the body is sent but under a symbol property and uncloned. Exposing it publicly (maybe under bodyReceived or some other name) and cloning it so it can be used twice would be exactly what I need. Receiving a buffer would also be very useful.
Since it is using request, rather than fetch, it is using a node Readable stream so we can't just tee the stream.
I have also considered...
Additional context
The implementation previously used was not performant and didn't need to be because it was only supposed to be used when something majorly messed up.
This would solve...
In a library I am working on, they had 2 events (request & response) that would fire before and after a request was made. The purpose of these events was for analytics (ie. receiving a "weird" response code and checking the body). With undici, I'm hoping that these events can be removed entirely and instead use the
diagnostics_channelsupport (the library only supports v16.9.0+).The implementation should look like...
In the
requestproperty, the body is sent but under a symbol property and uncloned. Exposing it publicly (maybe underbodyReceivedor some other name) and cloning it so it can be used twice would be exactly what I need. Receiving a buffer would also be very useful.Since it is using
request, rather thanfetch, it is using a node Readable stream so we can't just tee the stream.I have also considered...
Additional context
The implementation previously used was not performant and didn't need to be because it was only supposed to be used when something majorly messed up.