Closed ulisesbocchio closed 11 months ago
Same here... To be honest, I don't think that "fix" should have ever been applied. The comment in the commit points to the relevant piece of code in Node.js: setting destroyed: true
essentially is stopping Node.js from actually destroying the underlying socket (potentially creating memory leaks).
I submitted the PR https://github.com/ladjs/superagent/pull/1774 to address this.
v8.1.0 released which fixes this issue, thank you
npm install superagent@8.1.0
release notes @ https://github.com/ladjs/superagent/releases/tag/v8.1.0
I just upgraded my codebase to latest version of superagent and noticed my unit tests breaking because of this: https://github.com/visionmedia/superagent/blob/29fd1f917a6cc78c9a2a9984269c06f8b4e63dcb/src/request-base.js#L505-L508
When I remove that line, they pass. I'd like to know what exactly are you referring to in your comment. In Node 16 LTS
req.abort()
works as expected without having to set the flag manually. Also, the documentation now discourages the use ofreq.abort()
in favor ofreq.destroy()
which I tested and works great too. For instance you could doreq.destroy(new Error('Aborted'))
. To give you an example of how setting that flag does't work as expected here's some reference code:Basically here there's a request going out to a server with a handler that's gonna abort that request while it's being handled. The handler has an "access logger" that logs out the result of the server side request, and the superagent request result is also logged when aborting the superagent request you'd expect this output:
but instead you get: