Flow application (23) complains Resynchronizing UI by client's request in one cloud env

My application is java (11) with flow (vaadin 23.0.8). In one cloud deployed region, we get a bunch of instances where the user end up with a blank screen and the server side logs the following:
2022-11-30T16:14:23,940 WARN [http-nio-8080-exec-9] (ServerRpcHandler.java:324) .v.f.s.c.ServerRpcHandler [] - Resynchronizing UI by client's request. A 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
Exactly the same build of the software is deployed identically in other regions. We don’t see any evidence of the GCP-supplied LB problems, the server isn’t getting moved or restarted, and there isn’t any obvious issue with networking environment or resource constraints.

So, I’m looking for hints how to debug and/or fix this.

Did you find a solution for the issue?

@quintessential-ibex sadly fairly widespread and random problem. See https://github.com/vaadin/flow/issues/14797

Uh, seems nasty. Have you faced that as well?

I’ve faced it within corporate environments with multiple firewalls, sloppy network availability, DNS resolution slowness and greedy proxies with Anti Virus programs that mingle with the response - insanely hard to debug or even reproduce… I’m wondering if therr should be a way for flow to cache 1-3 requests on the server and if the client requests an old request again flow could re-send it instead of “failing” but haven’t advertised this idea so far

Happens here, too, from time to time…
Resynchronizing UI by client’s request sometimes, no Idea why, waiting for the next occurence to have a better peek at the logs.

And also once we had this constant reloads. But only at one user, I could connect same time without issues…

Yet now idea about that…
:man_shrugging:

Yeah it’s something in between that user’s Webbrowser and the server - nothing you can reproduce on your end :slightly_frowning_face:

These are nasty things to fix with workarounds as repeating the issue don’t seem to be deterministic. Push all the details you have to that ticket, those can be the critical pieces of info that will help Mikael et al to get it fixed.

I remember that I used a tool called dummynet in the past to develop fixes for some communication issues. But don’t know the internals of the current framework that well anymore that I could attack this issue :sweat:

FWIW, we don’t get a loop but rather a static empty white window with nothing else interesting in the server side logs. We use push in default mode and with default parameters. The only other thing I can think of that might be relevant is that we only see it happen with a high frequency on an instance deployed to GCP in the europe-west2-a region/zone. At some level, I’d love to just blame GCP, but I cannot find any networking logs that indicate any obvious coincident issues.

So no - no solution or ideas how to debug or workaround, only more user complaints :stuck_out_tongue:

Hi! With my new application, I have the same situation - white empty page from time to time https://discordapp.com/channels/732335336448852018/1048729162455711794 I do not see any issues in the log ( Only resync sometimes

have you caught it yourself and can you see anything on the client side? The only person in my case who sees it regularly isn’t local to me so I can’t get into the dev console easily.

I see this(the white screen) very often on my iPhone after being idle for a while. On the client side, I only see the resync issue

okay - I just caught it happening and some observations…

  1. I see “Websocket closed” warnings from push between during almost every page navigation in this tenant. I [edit: do] see this in other tenants running exactly the same software deployed to other GCP regions, but do not see the following.
  2. when I got a “white screen” failure, there’s a javascript “Client is resynchronizing” error (see snapshot 1).
  3. the DOM lacks anything application-specific. All the CSS is there, but where all the content should be, there’s only a
    with one empty child element (see snapshot 2)
  4. the network log indicates multiple stalled websocket push interactions (see snapshot 3 - ignore the NaN error in the console log as that’s a completely different component issue).

It is also worth mentioning that this happens while actively using the application - we’re definitely not timing out due to inactivity and the above error occurred approximately 5 minutes into the session.

@yummy-rhino references a similar (same?) issue in https://stackoverflow.com/questions/74081025/vaadin23-uncaught-in-promise-error-client-is-resynchronizing saying that it (something) has been fixed in 23.2.5. We are definitely using grid/grid-pro.

It’s similar in the result but has different root cause.

vaadin 23.0.8
I think the mentioned fixes are not in that version, I recommend to go for e.g. the latest 23.2.11

In general, there are three things to mention here

  1. The actual issue is in the flakiness of infrastructure, as mentioned by @quirky-zebra . In that case you should be happy about seeing this warning in the log, as it is failsafe mechanism intended for such cases. We are logging the warning, so that you are aware that something is happening. And if it is faulty infra, that should be fixed. It can be VPN, wrong proxy settings, etc.
  2. Note, if the resync is not fully working, i.e. you need to refresh to continue, that is signaling that either something is really bad in infra, or there issue in the resync mechanism itself. We have done couple of fixes in the mechanism during course of time.
  3. It could be that resync is triggered due bug in the framework. We never can rule this out, even when the track record is generally robust. We have done some fixes in the framework during course of time.