fix: prevent handling in-flight requests after worker was stopped#2668
Draft
diego-aquino wants to merge 1 commit intomswjs:mainfrom
Draft
fix: prevent handling in-flight requests after worker was stopped#2668diego-aquino wants to merge 1 commit intomswjs:mainfrom
diego-aquino wants to merge 1 commit intomswjs:mainfrom
Conversation
This adds two temporary test cases to help us investigate requests still being handled by workers after they are stopped. Related to mswjs#2597.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I was investigating #2597 and comparing the reproduction repository with MSW's test suite. The reproduction tests frequently fail due to requests still being handled after the worker was stopped.
However, the existing MSW test checking this behavior does not appear to be flaky:
msw/test/browser/msw-api/setup-worker/stop/in-flight-request.test.ts
Line 31 in 5ab5857
I've created two new test cases to better understand the problem:
bypasses requests not immediately made after the worker was stopped, considering no default responseThis test stops the worker and makes a request in different
page.evaluatecalls. It checks if the request was bypassed by expecting aCannot GETresponse text. From my local executions, it always passes.bypasses requests immediately made after the worker was stopped, considering no default responseThis test stops the worker and makes a request in the same
page.evaluatecall. Similarly to test 1, it expects aCannot GETresponse text, but it shows the same flaky behavior as the reproduction tests, although less frequently.Here's an example of a failure:
Note
I've added a for loop to repeat the new tests and make them more likely to fail. Still, not all test executions cause failures. Run them a couple of times if they continue to pass.
Maybe the overhead of
page.evaluateis masking the issue in the existing test?This pull request does not yet contain any changes to the source code. I've only added tests trying to simulate the issue.
@kettanaito, as I'm new to the codebase, I'm not yet sure about how to fix this. I'm willing to contribute after hearing your feedback and possible courses of action. Thanks!
Closes #2597.