ClassNotFoundException for transient classes during Vaadin UI restoration

Answer first

Client-side SessionStorage is not a valid persistence mechanism for server-side UI state across server restarts. SessionStorage is browser-tab scoped, cleared on tab close and by browser expiry/privacy policies, and Vaadin Flow does not reconstruct server component instances from it. It is used for client-side navigation hints only.

Restoration after a server restart requires server-side session and state restoration, not client SessionStorage. UI JSON serialization is for client-server sync within a live session, not durable backup.

Confirmed facts

• Vaadin Flow keeps the component tree and UI state server-side. The server holds the authoritative state nodes.
• UI serialization to JSON is for live client-server communication. It is not a durable backup format.
• Verification of recovered data in this scope assumes the underlying database remains intact and does not cover external migrations or schema drift.

Likely explanation for ClassNotFoundException for transient classes

Likely explanation, not confirmed: a custom component serializes a reference to a non-serializable, Spring proxy, or application-specific class via a field that is not properly marked transient, or the class is absent after classpath change during restore. Deserialization after backup restore then fails because the class cannot be found or is incompatible.

Transient fields that hold required state cause silent data loss on restore if they are not reconstructed. Marking a field transient removes it from serialization.

Component identifier equivalence between saved snapshot and restored UI session

Equivalence is determined by Vaadin internal state node identity and stable element identifiers, not by user data.

• Same UI instance context and session
• Same component type
• Same logical element id or state node path as stored in the snapshot
• Matching serialization schema version

Without all four, the snapshot cannot be safely mapped to a live component.

Restoration definition when Vaadin minor version changed JSON serialization format

Treat the snapshot as incompatible. Do not attempt automatic deserialization.

Define restoration as best-effort rebuild of UI from application state with an explicit version gate that rejects incompatible snapshots, or require version pinning for restores. Discard old UI state and recreate the view from backend data.

Verification steps needed for this case

1. Confirm server-side session storage mechanism used by the deployment and verify no server UI state is expected to be rebuilt from client SessionStorage.
2. Reproduce restore with identical Vaadin minor version and classpath to isolate ClassNotFoundException to transient field or missing class.
3. Inspect custom components for non-serializable or Spring proxy references. Ensure proper transient handling and reconstruct state in attach listeners or @PostConstruct, not via deserialization.
4. Check saved UI state version metadata against current Vaadin version and enforce a version gate that rejects incompatible snapshots.

Missing diagnostic detail

Which Vaadin minor versions are present in the backup snapshot versus the restore environment, and which class name appears in the ClassNotFoundException. This changes the recommendation on whether to rebuild UI from application state or attempt a version-aligned restore.