Testing abort signal / timeout

[jonyo]

I couldn't find anything mentioning ways to test abort signals using AbortController and passing in signal in the fetch options.

I tried testing a timeout by using ctx.delay(100) in the returned response, it did seem to delay the response but the timeout did not kick in (or did not have any effect). I added console logs, the timeout function which called abortController.abort() was called before the response came back but it seemed to be ignored by MSW.

The other side is testing that previous request gets cancelled successfully. We have something that cancels the previous request if the filters for the request change before the response is received (think of a user interacting with search filters and they make additional changes before the previous results come back).

Is it even possible to test signal behavior and cancelling a request early with MSW?

[JesusTheHun]

Calling ctx.delay(100) will only delay the response ; it does not involve request timeout.

If my PR is merged it will allow to expose a method on the server to abort all pending requests.

server.close()
server.listen(...)

// or a new method
server.abortRequests()

I just submitted another PR that fixes the issue with the AbortController signal

[Twipped]

@jonyo Did you ever find a solution for this? Presumably the aborted request would close its connection, so could there be some way to detect that early termination?

[jonyo]

Sorry I missed your reply.

No I didn't find a solution, but note that this was using the 1.x and I have not tried again in the newer MSW version.

could there be some way to detect that early termination?

Hmm, I suspect maybe if the request mock function implemented it on its own, I think I may have tried that but its been too long. Not sure if the mock function could get access to the signal passed in or not. But if it could, maybe you could build it into the mocked function?

Thinking on it more, perhaps that is the intent, that it would be up to the request handler function to deal with it. If that is the case though, it would be nice if something was mentioned in the docs with a simple use case, for times you want to mock the cancel signal getting triggered before the request resolves (or "fake resolves").