Leif Åstrand

Interesting case since it's based on the request rather than the response. Those "JS snippets" are just map keys that define what JS he client was running to produce each...

Another reason for adopting an approach where JS invocations are defined by an interface has popped up with the new support for passing arbitrary objects as parameters that are encoded...

> These even occur within the access/accessSyncronously Methods (first and second stacktrace) The issue in 99% of all cases is that there's one thread that doesn't do proper lock that...

It would further hide the underlying problem that application logic updates UI state from multiple threads at the same time. For that to work, all components, including all add-ons and...

The framework has a `checkHasLock` method to check that operations that touch UI state are run with appropriate locking. This is enabled by default in development mode but in production...

> But I also don't quite understand why methods within Ui and VaadinSession that are known to require a lock, as indicated by the use of checkHasLock, don't force the...

I added some additional checks in https://github.com/vaadin/flow/pull/22783. You can subscribe to that PR to get a notification when it's included in a release. There's one code path without `checkHasLock()` that...

`executeJs` only modifies `pendingJsInvocations` through a `StateTree.beforeClientResponse` callback rather than directly when invoked. On the other hand, calling `StateTree.beforeClientResponse` to schedule that callback goes through `checkHasLock()`. A no-op `checkHasLock()` with...

The additional checks have been released in Vaadin 24.9.6. If you could check whether the new checks would have caught the issues you had before you fixed them, then that...

The router is based on the the assumption that the same view type but different parameters is a navigation _within_ the same view rather than navigation to a new view...