Resynchronizing UI by client's request

[jonasrotilli]

Description of the bug

I am often getting the message in the log of Resynchronizing UI by client's request.

The full message is:
Resynchronizing UI by client's request. The network message was lost before reaching the client and the client is reloading the full UI state. This typically happens because of a bad network connection with packet loss or because of some part of the network infrastructure (load balancer, proxy) terminating a push (websocket or long-polling) connection. If you are using push with a proxy, make sure the push timeout is set to be smaller than the proxy connection timeout

It's not connection, apparently it's session related.

I have on the same linux server running another Vaadin 8 application.
They have different names, different ports, in different folders and are NGINX-mapped with different subdomains.

I have already evaluated the other problems related to the topic:
#12640
There was no clear solution, someone raised some possibilities:

• Browser, it's not in my case, it wouldn't happen so often.
• HTTP proxy, I use NGINX for the subdomains, but I use other services like NODE, static HTML and never had a problem. NGINX was configured by default, without any additional configuration, it just throws the subdomain to port X.
• Possibility of mixing sessions: it makes no sense, since I have very little load, it happens even with only 1 user logged in.

#12173
In this problem the user uses long duration push. Not my case, I use simple, default @Push.

#11645
In this problem as I understand it was the slow connection. It's not my case, everything is flying here.

#12173
In this problem the user uses long duration push. Not my case, I use simple, default @Push.

#10096
This is a very similar scenario. But there was no conclusion, the user closed without informing how the issue was resolved and if it was resolved.

#9399
This one he solved by changing the server, it is difficult to assess what the problem was

Anyway, this problem is quite recurrent and should be better explained in the documentation. I downloaded the example available from the site, nothing out of the ordinary, little or no extra configuration.

Expected behavior

The expectation is that it doesn't lock the user's screen, it's terrible to have to ask him to refresh the page, because after it's broken it doesn't come back.

Minimal reproducible example

It's hard to simulate, because it doesn't always happen.
The impression is that it happens after a while without changes on the page, but sometimes it happens right after logging in or during some slower operation.

Versions

• Vaadin / Flow version: 23.2.0.alpha1

• Java version:
  openjdk version "11.0.3" 2019-04-16
  OpenJDK Runtime Environment (build 11.0.3+7-Ubuntu-1ubuntu218.10.1)
  OpenJDK 64-Bit Server VM (build 11.0.3+7-Ubuntu-1ubuntu218.10.1, mixed mode, sharing)

• OS version:
  -Ubuntu

• Browser version (if applicable):
  Chrome

[jonasrotilli]

Difficult.
I increased the timeout on NGINX to 600 seconds and the problem continues.

[tiagomartins91]

Same on Vaadin version 14.8.14

WARN com.vaadin.flow.server.communication.ServerRpcHandler [http-nio-8080-exec-3] Resynchronizing UI by client's request. Under normal operations this should not happen and may indicate a bug in Vaadin platform. If you see this message regularly please open a bug report at https://github.com/vaadin/flow/issues

[jonasrotilli]

tiagomartins91

Apparently no one from Vaadin is watching here..
Let's try to find the problem ourselves, try to see what we have in common.
1 - Do you have any other Vaadin application running on the same server?
A: I do, but it's another folder, another version, nothing shared.

2 - Does it happen in development, when running with Intelij or similar?
A: No.

3 - Does it happen in production?
A: Yes, I stop the service and put a new version, first login most of the time happens, which disproves the theory that it's because of time without moving.

[jonasrotilli]

I was hoping to be a conflict between two applications.
But it is not. I completely stopped the other application and started the new one, Vaadin 23.

And the same problem happened:
Resynchronizing UI by client's request. The network message was lost before reaching the client and the client is reloading the full UI state. This typically happens because of a bad network connection with packet loss or because of some part of the network infrastructure (load balancer, proxy) terminating a push (websocket or long-polling) connection. If you are using push with a proxy, make sure the push timeout is set to be smaller than the proxy connection timeout

This is very bad, it is a very serious problem.

[knoobie]

I would suggest to post your nginx and push configuration.

[jonasrotilli]

Sugiro postar sua configuração nginx e push.

Push detault:

@Theme(value = "myapp")
@PWA(name = "upCampo", shortName = "upCampo")
@NpmPackage(value = "line-awesome", version = "1.3.0")
@Push

NGINX file:

server {

    server_name  novoportal.MYWEBSITE;

    location / {
        proxy_pass  http://127.0.0.1:1628;
    }

    listen [::]:443 ssl; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/novoportal.MYWEBSITE/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/novoportal.MYWEBSITE/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


}
server {
    if ($host = novoportal.MYWEBSITE) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;

    server_name  novoportal.MYWEBSITE;
    return 404; # managed by Certbot

   proxy_read_timeout 600;
   proxy_connect_timeout 600;
   proxy_send_timeout 600;


}

About the timeouts in NGINX, I added more time, it didn't make any difference with or without this part of the code:

   proxy_read_timeout 600;
   proxy_connect_timeout 600;
   proxy_send_timeout 600;

[knoobie]

I don't see anything related to push in the configuration. Cuba has a example for nginx that you could try: https://doc.cuba-platform.com/manual-latest/server_push_settings.html#server_push_settings_using_proxy - important is the part about upgrade

I'm more experienced with apache httpd and there it is a must have to configure websockets corretly to work in corporate networks.

[jonasrotilli]

Não vejo nada relacionado ao push na configuração. Cuba tem um exemplo para nginx que você pode tentar: https://doc.cuba-platform.com/manual-latest/server_push_settings.html#server_push_settings_using_proxy - importante é a parte sobreupgrade

Eu sou mais experiente com apache httpd e aí é necessário configurar websockets corretamente para trabalhar em redes corporativas.

I added your suggestion in NGINX.
Good news: so far, the problem hasn't happened yet.
I'll leave it running during the day and come back here to confirm if it worked or not.

Thank you very much!

[jonasrotilli]

I don't see anything related to push in the configuration. Cuba has a example for nginx that you could try: https://doc.cuba-platform.com/manual-latest/server_push_settings.html#server_push_settings_using_proxy - important is the part about upgrade

I'm more experienced with apache httpd and there it is a must have to configure websockets corretly to work in corporate networks.

Sorted out!
Big help. I accessed the CUBA link and used the "location" part, it seems that there is something related to WebSocket support.
Since putting it on, I haven't had any more problems.
@knoobie Thank you so much for your help, it saved me from several nights sleep!

I share here my NGINX that I'm using for other users, and I won't close the ticket so that someone from Vaadin can evaluate if any improvement is needed in relation to the theme.
I believe this could be in the documentation.

Here's the complete file:

server {

server_name  mywebsite.com;

 location / {
     proxy_set_header X-Forwarded-Host $host;
     proxy_set_header X-Forwarded-Server $host;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_read_timeout     3600;
     proxy_connect_timeout  240;
     proxy_set_header Host $host;
     proxy_set_header X-RealIP $remote_addr;

     proxy_pass  http://127.0.0.1:PORT_EXIT_DO_YOUR_SPRINGBOOT;

     proxy_set_header X-Forwarded-Proto $scheme;

     proxy_set_header Upgrade $http_upgrade;
     proxy_set_header Connection "upgrade";
}

 listen [::]:443 ssl; # managed by Certbot (Certificate SSL)
 listen 443 ssl; # managed by Certbot (Certificate SSL)
 ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem; # managed by Certbot (Certificate SSL)
 ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem; # managed by Certbot (Certificate SSL)
 include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot (Certificate SSL)
 ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot (Certificate SSL)


}
server {
 if ($host = mywebsite.com) {
     return 301 https://$host$request_uri;
 } # managed by Certbot


 listen 80;
 listen [::]:80;

 server_name  mywebsite.com;
 return 404; # managed by Certbot (Certificate SSL)

proxy_read_timeout 600;
proxy_connect_timeout 600;
proxy_send_timeout 600;

}

[knoobie]

I believe this could be in the documentation.

How to configure a reverse proxy should be an important topic inside the docs (cc: @tarekoraby)

[jonasrotilli]

I have bad news.
Monitoring since that day and it happened again.
Less often than before the NGINX change but it is happening.
Any other possible problems?

[tiagomartins91]

Same here

[jonasrotilli]

That is terrible. We never had problems like this in the old Vaadin 8 application.
Imagine the inconvenience this is causing the customer.
This image makes me shiver every time I see it:

Please someone help us!

Remove the documentation topic, not only that, it's something very serious that needs to be investigated.

[tarekoraby]

I would personally try to obtain a debug log of nginx to try to understand what's happening.

[jonasrotilli]

Eu pessoalmente tentaria obter um log de depuração do nginx para tentar entender o que está acontecendo.

I am fully available to collect the data needed to resolve this issue.

Help me, how do I do this?

[tarekoraby]

I'm not an nginx expert, but I'd check the docs for instructions on that: https://nginx.org/en/docs/debugging_log.html.

[tiagomartins91]

Any update? Still happens sometimes and needs to refresh the page for the application work

[mshabarov]

We are going to investigate it more closely in the upcoming development iteration.

[kagian]

I've managed to reproduce this issue almost consistently. There are a couple of interesting factors that lead into this. I have a pcap and a google chrome debug output and the code that generates the issue.

java.lang.UnsupportedOperationException: Unexpected message id from the client. Expected sync id: 9, got 10. more details logged on DEBUG level.

On the following above, I noticed that in both pcap and and the Google Developer network tab that only a sync for 8 and 10 were generated from the server.

In the PCAP I can see that the Websocket port actually generates a FIN packet in between of both the id 8 packet being generated and id 10. Further data however is still being sent on the socket, which is technically fine. I am unclear why the server thinks that Id 9 got generated. But in the specific instance I looked up the FIN was generated and might be related. As a general note, in reading about this issue in other places, it mentions network quality, and I agree to this fact. We're having latency around 300ms to the server and client and slightly high packet loss ~30%. As this is TCP however, it really shouldn't be impacting the order and number of packets being finally received by server and client as re-transmissions should end up succeeding.

For most of my code I am already using my UI code as ui.access(command). I was also using @Push(PushMode.AUTOMATIC). I am unclear if this is related.

I moved to using @Push(PushMode.MANUAL) with ui.push after the ui.access and I have not been able to reproduce this problem straight after.

I have a PCAP for this I would prefer to hand it over to someone at Vaadin directly as there is likely confidential data within the data.

My suspicion therefore is that the Push automated sync messages logic has some server side bug.

This was tested on version 22.0.2

[knoobie]

@kagian Please share it, if you wanna see steady progress in this topic.

[flefebure]

Our multi-years Vaadin 7->14 migration work just went in production.

During dev/tests period, we had occasionnally this problem, principally when remote working, with a bad network.
But now we have more users, and users with various network configuration, we realize that the problem is more serious than expected.
We speak a lot of NGinx in this thread, my feeling is that this problem is not reverse-proxy related.
For sure we have an NGinx in front of the app, but we also access directly the tomcat port, and we can see the problem at the same frequency.
My short term goal is to produce a small project that reproduces the problem, for the Vaadin team.
I'll probably use one of those browser extensions that simulates a bad network.

This problem is very critical, and as someone said, it wasn't observable with the old 7/8 vaadin platform

[vaadin-bot]

This ticket/PR has been released with Vaadin 14.9.0.beta1 and is also targeting the upcoming stable 14.9.0 version.

[jonasrotilli]

This issue has not been resolved.
It keeps happening, even in the latest version 23.2.9.
Right now I'm seeing this happen, in production, internet ok, 1 hour with the screen open without moving, when changing screens, the problem started.

This is complicated, it's been 6 months since my report and it keeps happening, version comes in, version comes out and there is no solution or definitive explanation.

[echarlus]

I've also seen it a few times with 23.3.1 :(

[jonasrotilli]

I just updated to 23.2.9, and the finding is that it's much worse.
It happened 2 times already, just with me as I'm a system developer.

I will need to go back to the previous version.

This issue has not been resolved. It keeps happening, even in the latest version 23.2.9. Right now I'm seeing this happen, in production, internet ok, 1 hour with the screen open without moving, when changing screens, the problem started.

This is complicated, it's been 6 months since my report and it keeps happening, version comes in, version comes out and there is no solution or definitive explanation.

[jonasrotilli]

This item needs to be re-opened, it has not been resolved.

[jonasrotilli]

See the browser log messages, when they happen:
.
.
.
.

Tue Jan 10 2023 16:00:58 GMT-0400 (Horário Padrão do Amazonas) Atmosphere: Firing onClose (closed case)
vaadinPush-min.js?v=23.2.3:1 Tue Jan 10 2023 16:00:58 GMT-0400 (Horário Padrão do Amazonas) Atmosphere: Request already closed, not firing onClose (closed case)

vaadinPush-min.js?v=23.2.3:1 Tue Jan 10 2023 16:00:58 GMT-0400 (Horário Padrão do Amazonas) Atmosphere: invoking .close() on WebSocket object

2vaadinPush-min.js?v=23.2.3:1 Tue Jan 10 2023 16:00:58 GMT-0400 (Horário Padrão do Amazonas) Atmosphere: Firing onReconnect

vaadinPush-min.js?v=23.2.3:1 Invoking executeWebSocket, using URL: wss://portal.upcampo.com.br/?v-r=push&v-uiId=0&v-pushId=c72c1567-11f6-4e9f-81ab-d51fd96ba37e&X-Atmosphere-tracking-id=725954af-eeb4-42ca-94a0-7905083d0fec&X-Atmosphere-Framework=3.1.2-javascript&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&Content-Type=application/json; charset=UTF-8&X-atmo-protocol=true
vaadinPush-min.js?v=23.2.3:1 Tue Jan 10 2023 16:01:05 GMT-0400 (Horário Padrão do Amazonas) Atmosphere: websocket.onopen

vaadinPush-min.js?v=23.2.3:1 Websocket successfully opened
vaadinPush-min.js?v=23.2.3:1 Tue Jan 10 2023 16:01:05 GMT-0400 (Horário Padrão do Amazonas) Atmosphere: websocket.onmessage

2vaadinPush-min.js?v=23.2.3:1 Tue Jan 10 2023 16:01:05 GMT-0400 (Horário Padrão do Amazonas) Atmosphere: Firing onReopen

generated-flow-imports.81274417.js:894 WARNING: Since Vaadin 23, notifyResize() is deprecated. The component uses a ResizeObserver internally and doesn't need to be explicitly notified of resizes.

notifyResize @ generated-flow-imports.81274417.js:894
11FlowClient.947c8d40.js:1 Uncaught (in promise) Error: Client is resynchronizing
at FlowClient.947c8d40.js:1:42744
at Array.forEach ()
at Zy (FlowClient.947c8d40.js:1:42719)
at by (FlowClient.947c8d40.js:1:34159)
at z.db (FlowClient.947c8d40.js:3:76660)
at x (FlowClient.947c8d40.js:1:32329)
at Map.forEach ()
at i2 (FlowClient.947c8d40.js:1:43877)
at W1 (FlowClient.947c8d40.js:3:50372)
at mf (FlowClient.947c8d40.js:3:37591)
at z.Bb (FlowClient.947c8d40.js:3:74625)
at z.O (FlowClient.947c8d40.js:3:86799)
at XMLHttpRequest. (FlowClient.947c8d40.js:1:25882)
at od (FlowClient.947c8d40.js:1:16760)
at Z2 (FlowClient.947c8d40.js:3:5692)
at XMLHttpRequest. (FlowClient.947c8d40.js:1:28235)

[jonasrotilli]

Curious that it happens a lot more on Mac computers.
I tested it on more than one mac computer and it happened on both.
Already on a Windows, the problem occurs much less frequently.
I tested it in Google Chrome browser and Safari, in both the same behavior. If I open the browsers log, it shows an error:

(in promise) Error: Client is resynchronizing at FlowClient.42a5821f.js:1:42438

We need an urgent solution for this, the situation is becoming unsustainable, many customers are complaining.

There are several tickects open for this and no solution:
#15205
#14797

I am ready to help you by providing information.
If anyone wants to connect to my computer and look at the problem happening, if they want my project, anyway, I'm available to help with the definitive resolution.

[knoobie]

If you can reproduce the problem locally, that would probably help a lot.

Additionally you can enable trace logging to https://github.com/vaadin/flow/blob/master/flow-server/src/main/java/com/vaadin/flow/component/internal/UIInternals.java which would print all information why the server side count increases (A LOT) to find the cause why / how it happens. (This should not be added to a production env)

[mshabarov]

@jonasrotilli thanks for willing to help on this issue. Would you be up for a call to discuss and see what is happening on your side? Please email me mikhail@vaadin.com and we can then arrange a meet. We are working on the other issues related to client-server resynchronisation, but since this one is getting worse, we'll work on it asap.

[jonasrotilli]

If you can reproduce the problem locally, that would probably help a lot.

Additionally you can enable trace logging to https://github.com/vaadin/flow/blob/master/flow-server/src/main/java/com/vaadin/flow/component/internal/UIInternals.java which would print all information why the server side count increases (A LOT) to find the cause why / how it happens. (This should not be added to a production env)

I don't have the problem locally, only when it's production.
What I meant is that we can make a call to view here on my computer occurring in production.
There was a time when the problem was random. Now it happens in a pattern: just let the system stand still for a few minutes, it happens.

[jonasrotilli]

@jonasrotilli thanks for willing to help on this issue. Would you be up for a call to discuss and see what is happening on your side? Please email me mikhail@vaadin.com and we can then arrange a meet. We are working on the other issues related to client-server resynchronisation, but since this one is getting worse, we'll work on it asap.

I sent my data, so we can talk, thanks!

[jonasrotilli]

Se você puder reproduzir o problema localmente, isso provavelmente ajudará muito.

Além disso, você pode ativar o registro de rastreamento em https://github.com/vaadin/flow/blob/master/flow-server/src/main/java/com/vaadin/flow/component/internal/UIInternals.java que imprimiria todos informações por que a contagem do lado do servidor aumenta (MUITO) para encontrar a causa / como isso acontece. (Isso não deve ser adicionado a um ambiente de produção)

Could you help me to put this TRACE?
Is there somewhere with an explanation how should I use it?

It would help me a lot, thanks.

[knoobie]

In Spring Boot for example add this to your application.yml (you probably already have the top level entries):

logging:
  level:
    com.vaadin.flow.component.internal.UIInternals: TRACE

[jonasrotilli]

No Spring Boot, por exemplo, adicione isso ao seu application.yml (você provavelmente já possui as entradas de nível superior):

logging:
  level:
    com.vaadin.flow.component.internal.UIInternals: TRACE

I don't use application.yml, I use application.properties, if you have the lines ready, help me!
I'm searching

[mshabarov]

@jonasrotilli
this works for me
add logging.level.com.vaadin.flow.component.internal = trace in application.properties

[jonasrotilli]

After help from @mshabarov and @mcollovati , they guided me to put version 23.2.13.
In this version the problem is gone.
No other changes were made, I didn't touch NGINX, anything in the application or anything related to the server, so I believe that something between version 23.2.9 and 23.2.13 solved the problem.

Thanks for the help!

I won't close, so that someone with more knowledge can assess what has been done between these versions.

[Artur-]

#14887 was fixed in 23.2.12 and 23.3.2. There does not seem to be any comments here about newer versions experiencing the problem

[mshabarov]

Closed because the issue is not reproduced for author. If anyone would experience the same issue again, please report it here, so we can re-open and investigate, or make a new issue in Flow.

[dbMe1]

Intermittently, in PROD environment only, I am seeing:
UnsupportedOperationException: Unexpected message id from the client. Expected sync id: 3, got 4

JDK 17
Spring Boot 3.2.0
Vaadin 24.2.4

Please help.
Here is most of the stacktrace:

2023-12-17T04:58:32.360Z ERROR 7 --- [dbME] [nio-6386-exec-9] c.v.flow.server.DefaultErrorHandler :

java.lang.UnsupportedOperationException: Unexpected message id from the client. Expected sync id: 3, got 4. more details logged on DEBUG level.

at com.vaadin.flow.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:313) ~[flow-server-24.2.3.jar!/:24.2.3]

at com.vaadin.flow.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:114) ~[flow-server-24.2.3.jar!/:24.2.3]

at com.vaadin.flow.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:40) ~[flow-server-24.2.3.jar!/:24.2.3]

at com.vaadin.flow.server.VaadinService.handleRequest(VaadinService.java:1522) ~[flow-server-24.2.3.jar!/:24.2.3]

at com.vaadin.flow.server.VaadinServlet.service(VaadinServlet.java:398) ~[flow-server-24.2.3.jar!/:24.2.3]

at com.vaadin.flow.spring.SpringServlet.service(SpringServlet.java:106) ~[vaadin-spring-24.2.3.jar!/:na]

at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:642) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:408) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:313) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:277) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.springframework.web.servlet.mvc.ServletForwardingController.handleRequestInternal(ServletForwardingController.java:141) ~[spring-webmvc-6.1.1.jar!/:6.1.1]

at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:178) ~[spring-webmvc-6.1.1.jar!/:6.1.1]

at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:51) ~[spring-webmvc-6.1.1.jar!/:6.1.1]

at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1089) ~[spring-webmvc-6.1.1.jar!/:6.1.1]

at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:979) ~[spring-webmvc-6.1.1.jar!/:6.1.1]

at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1014) ~[spring-webmvc-6.1.1.jar!/:6.1.1]

at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:914) ~[spring-webmvc-6.1.1.jar!/:6.1.1]

at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:590) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:885) ~[spring-webmvc-6.1.1.jar!/:6.1.1]

at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) ~[tomcat-embed-websocket-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149) ~[tomcat-embed-core-10.1.16.jar!/:na]

at org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231) ~[spring-security-web-6.2.0.jar!/