-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: ensure that requests to the same resource will be properly intercepted even if they are sent in rapid succession #30435
fix: ensure that requests to the same resource will be properly intercepted even if they are sent in rapid succession #30435
Conversation
…cepted even if they are sent in rapid succession - run ci
cypress Run #57809
Run Properties:
|
Project |
cypress
|
Branch Review |
ryanm/chore/fix-racing-net-stubbing-flake
|
Run status |
Passed #57809
|
Run duration | 12m 25s |
Commit |
339a450fe3: PR comments
|
Committer | Ryan Manuel |
View all properties for this run ↗︎ |
Test results | |
---|---|
Failures |
0
|
Flaky |
0
|
Pending |
4
|
Skipped |
0
|
Passing |
233
|
View all changes introduced in this branch ↗︎ |
UI Coverage
67.07%
|
|
---|---|
Untested elements |
25
|
Tested elements |
55
|
Accessibility
96.15%
|
|
---|---|
Failed rules |
0 critical
4 serious
1 moderate
0 minor
|
Failed elements |
206
|
}, | ||
}) | ||
|
||
state.pendingEventHandlers[frame.eventId](frame.data) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need a done
handler here or something similar in the case the fake for some reason is not called and the test passes when it shouldn't?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can't mix and match promises and done, but I figured a better way to ensure this is getting called: 339a450
(#30435)
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
Additional details
When requests go through the proxy, they execute the following middleware functions that affect
matchingRoutes
that get attached to the request:req
objectToday, the set of matching requests gets set and then we associate subscriptions here. We then proceed synchronously until we await the request body. In that time we could receive other requests that get their subscriptions defined. If the first request is supposed to surpass the maximum number of requests that a given interception can handle, it is supposed to not be available for the second one. However, since they've both had their associated subscriptions defined prior to being handled, this causes the first interception to apply to both requests.
This change removes the gap that can occur when multiple requests for the same resource occur in rapid succession by moving the subscription association to after the async awaiting of the request body. We then do a sanity check when adding the subscriptions to ensure the routes we are using are not disabled.
Steps to test
Added some unit tests for this as it is very difficult to reliably test in a more integrated fashion
How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?