Vaadin Push fails during session deserialization

[MichaelPluessErni]

Error:

During session deserialization it can happen, that vaadin pushes fail and trigger a refresh.

Expectation:

Refreshs should not be triggered during session deserialization.

More details:

I suspect that the push process and the deserialization process run in parallel and can interfere.

Versions:
Flow: 24.3.5
Vaadin: 24.3.4
Spring Boot: 3.2.2
Java: Oracle Corporation 17
OS: amd64 Windows 10 10.0
Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Live reload: Java unavailable
(JRebel): Front end active

[mcollovati]

In this case, it appears that the Flow client, for some reason (page reload? Navigating away?), is closing the push connection (X-Atmosphere-Transport=close), not actually receiving updates, but what's weird is that the 405 response code.
Currently, I couldn't find any Flow nor Atmosphere code that is sending a 405.
Are there any relevant logs on the server related to the failing request?

[MichaelPluessErni]

@mcollovati Unfortunately, I could not find related messages in the logs.

[mcollovati]

Unfortunately, I'm unable to reproduce the PUSH 405 failure.
However, I think the PUSH request failure is a consequence of the page reload, not the cause.

For further investigation, it would be good to have the trace of the previous UIDL request (request + response payloads) and, if Spring Security is configured for the application, the server logs with category org.springframework.security at debug level.

[mcollovati]

@MichaelPluessErni additional question: is this happening in production or development mode?

[MichaelPluessErni]

@mcollovati this happens in production mode.

I'll have a look whether I can procure a logging trace as described in your previous post.

[mcollovati]

Testing locally, I had a confirmation that the POST PUSH request is caused by a page reload, not the opposite.
On page reload, Flow client closes the atmosphere connection, but it looks like that currently requests to /VAADIN/push are not considered as internal request and this may cause some Spring Security filter to check a request that should not be blocked.

[MichaelPluessErni]

I've been unable to replicate the 405 Error Code for some time. Instead I've observed different behaviour, that might be related:

When having the website open and restarting the pod, sometimes the website stays at it is (desired) and sometimes it reloads and goes back to the login screen (not desired).

In the case where it reloads, I've seen in the last "app/?v-r=uidl&v-uild=1" Request that two Set-Cookie headers were added. In most cases these headers are not present. Might this be related and cause a reload?

In cases where there was no reload, an "app/?v-r..." request was not present.

I hope this helps / gives a clue.

[mcollovati]

It would be good to know the contents of the UIDL request.
About the cookies, I think they are correct if the server changed.
Could you please also check that the request causing the reload has the clusterKey⁣ cookie correctly set? Without it, the session cannot be restored.

[MichaelPluessErni]

The clusterKey is set correctly.

Contents of the UIDL request:

Request headers:

:authority:
XXXX-3154.XXXX
:method:
POST
:path:
/app/?v-r=uidl&v-uiId=1
:scheme:
https
Accept:
*/*
Accept-Encoding:
gzip, deflate, br, zstd
Accept-Language:
de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Content-Length:
342
Content-Type:
application/json; charset=UTF-8
Cookie:
XXXX-config-point-of-sale=2875; clusterKey=4f090fde-90f8-4526-b91b-acc3591a9501; ingress-nginx-LB-cookie=6dfbdf159c4685fa5a1a066096b6f7a3|e307bd8c560d84365a1cbd65ac4ddd3d; JSESSIONID=18CB36FCF481A01E31D721D9F00A003C
Origin:
https://XXXX-gke-XXXX-3154.XXXX
Sec-Ch-Ua:
"Google Chrome";v="123", "Not:A-Brand";v="8", "Chromium";v="123"
Sec-Ch-Ua-Mobile:
?0
Sec-Ch-Ua-Platform:
"Windows"
Sec-Fetch-Dest:
empty
Sec-Fetch-Mode:
cors
Sec-Fetch-Site:
same-origin
User-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Payload:

{"csrfToken":"73ef5d1f-055e-40f3-8770-1357b60e08d7","rpc":[{"type":"event","node":84,"event":"click","data":{"event.shiftKey":false,"event.metaKey":false,"event.detail":1,"event.ctrlKey":false,"event.clientX":546,"event.clientY":819,"event.altKey":false,"event.button":0,"event.screenY":-534,"event.screenX":1526}}],"syncId":22,"clientId":22}

Interestingly, the reload seems to be triggered by a click on the website. It does not reload of its own beforehand.

[mcollovati]

Could you post also the content of the response?