Beacon request cancelation missing on page navigation in Cypress

[mduchemin]

We are encountering a situation where the testing environment causes a difference in behavior.
Environment: Chrome for Windows, v 127.0.6533.120

Context:

• The application tested is servlet based, with Spring-Security authentication
• When a request is made to the webserver, if there is currently no active session or if the session is invalidated, a new server-side session will be created. When this happens, the response will contain a cookie header setting the JSessionId cookie to the client.
• The application sends a beacon request to a dedicated endpoint on the server during window beforeUnload. This request is Async and non-blocking, so other browser behaviors continue while the request / response cycle occurs. This request is NOT expected to provide a response to the client, since beforeUnload triggers when the page is being destroyed (navigation, tab closing, etc.). Instead, its purpose is to notify the server that the client is unloading in order to perform server-side cleanup without waiting for session expiration. Since beacon is async and non-blocking, this allow the server to receive the request even if the emiting document has already unloaded by the time the request reaches the webserver, as the beacon request is not dependant on the source document.
• the beacon response may contain a setCookie header for JSessionId, if the previous session was invalidated or expired. Spring-security will automatically invalidate sessions during some operations, such as login with form. If navigation occurs just after session invalidation such as during login, both the beacon request and document request are sent holding the already invalidated JSessionID, so each separately create a new servlet session and their response contain each a different JSessionId cookie header.

Behavior

In a regular browser

The beacon request is sent when navigation to another page is requested (for example, by changing window.location).
This means that there are 2 competing requests emitted at the same time: Navigation document request and beacon notification request.

If the beacon request completes first, the document will receive the response first, setCookie, then receive the document response containing its own setCookie. In this case, the document's cookie is the final one because it overwrite the beacon cookie.

If the document request completes first, the beacon request is dropped by the browser. This doesn't prevent the request from completing its server-side purpose, but any response is discarded (including headers). In this case, the document's cookie is the final one because the beacon cookie is never set.

In Cypress testing environment

The difference is caused by the fact that the cypress environment doesn't actually unload and navigate away from the tested document. My understanding is that in the navigator tab, Cypress "emulates" the request / response transactions, and use the content to change the testing area. Since the beacon request is tied to Navigator, the request is not discarded by the browser as it

If the beacon request completes first, the document will receive the response first, setCookie, then receive the document response containing its own setCookie. In this case, the document's cookie is the final one because it overwrite the beacon cookie. This case is identical to the standard browser use case.

If the document request completes first, the beacon request is NOT dropped by the browser since the actual browser window hosting the cypress test suite is still the same context. As a result, the browser will perform the document's request setCookie, followed by the beacon's setCookie, which overwrites it.
As a result, the page will load the document, but use a different JSessionId cookie which doesn't match the document's context.

Questions:

• Is there any configuration switch to set cypress to discard responses to beacon requests emitted by a tested page which has already been unloaded?
• Is this intended in Cypress? If this is not up to current spec, should I create a bug or feature in the issues tracker?