vaadin / vaadin/spring

UIScope and RouteScope does not follow lifecycle of UI instance but actually the attach/detach

Open
#1,045 3 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug Impact: High Severity: Major
Dominant language
Java
Stars
186
Forks
98
PR merge metrics
No merged PRs in 30d

Description

Consider scenario where a proxy server breaks a websocket connection and then the "Resynchronizing UI by client’s request" happens. Internally ui.getInternals().getStateTree().prepareForResync() gets called.

What happens next is that the same existing UI instance will receive a detach event and then attach event. This will cause all UIScope and RouteScope beans to be cleaned on detach event and then re-created. So UIScope is not bound to actual UI instance lifecycle, but attach/detach lifecycle.

Documentation (https://vaadin.com/docs/latest/integrations/spring/scopes) talks only about UI lifecycle and nothing about attaching or detaching so either the documentation or implementation has to change.

Also javadoc of UI.onDetach says "Called before the UI is removed from the session. A UI instance is detached exactly once, either..." which is incorrect in this case. UI is not removed from session and onDetach can be called multiple times on same instance because of resync causes detach & attach without creating a new instance.

Observed with Vaadin 23.2.6.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the UIScope and RouteScope lifecycle described in the Spring scopes documentation, then trace UI.getInternals().getStateTree().prepareForResync() and the UI.onDetach javadoc. Reproduce the detach/attach sequence during websocket resynchronization and determine whether the implementation or documentation should reflect repeated events for one UI instance.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, spring
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.