Fix memory leak bug when re-using abortSignal (#2160)
#2161
Conversation
| @@ -545,6 +544,10 @@ export default class Request extends Duplex implements RequestEvents<Request> { | |||
| return this; | |||
| } | |||
|
|
|||
| private abortHandler(): void { | |||
There was a problem hiding this comment.
nit
| private abortHandler(): void { | |
| private _abortHandler(): void { |
| @@ -664,6 +667,7 @@ export default class Request extends Duplex implements RequestEvents<Request> { | |||
| response.once('end', () => { | |||
| this._responseSize = this._downloadedSize; | |||
| this.emit('downloadProgress', this.downloadProgress); | |||
| this.removeListener('abort', this.abortHandler); | |||
There was a problem hiding this comment.
This should be called on the signal instead
| @@ -674,6 +678,7 @@ export default class Request extends Duplex implements RequestEvents<Request> { | |||
| response.destroy(); | |||
|
|
|||
| this._beforeError(new ReadError(error, this)); | |||
| this.removeListener('abort', this.abortHandler); | |||
There was a problem hiding this comment.
response is not guaranteed, but request is. However listening on error request event is also incorrect because of retries. I'd suggest to move this to _destroy.
|
There is a possible fix here if it helps: marcelmeulemans@1bc4982 |
Great! I think this implementation fix #2160 correctly.
I will close this PR due to wrong implementation, and there comes out possible fix now. |
|
Would you like me to open a PR for that fix? If so any ideas for how to write a unit test for the issue? |
About unit test, I think you better ask for the question to this repository's maintainers. |
|
FYI #2162 I considered using the |
Checklist
This PR trying to fix #2160. (WIP)
abortHandlerof request instance will be removed when the response end or error, abort.