vaadin/flow 25.1.0-alpha11

Vaadin Flow 25.1.0-alpha11

on GitHub

Changes since 25.1.0-alpha10

All changes

Breaking changes

• Standardize signal callback interfaces
  Commit · Pull request

  Replace CleanupCallback with the existing Registration interface, change Signal.effect() parameter from SerializableRunnable to EffectAction, move SerializableExecutor and IntMapper (renamed to SerializableIntFunction) to com.vaadin.flow.function. Change wrapWithLock return type from Registration to SerializableRunnable.

New features

• Detect accidental sharing of ValueSignal with background threads
  Commit · Pull request · Issue

  When a ValueSignal instance has been used with modify() and also accessed without a locked VaadinSession, throw an IllegalStateException with guidance to use immutable values instead. This prevents silent data races because modify() temporarily releases its internal lock while the modifie callback runs, relying on the session lock for external synchronization.

• Detect accidental sharing of local signals between sessions
  Commit · Pull request · Issues 23535, 23535

  Local signals (ValueSignal, ListSignal) are intended for UI-local state within a single VaadinSession. When accidentally stored in a static field or application-scoped bean, they get silently shared across sessions, causing subtle bugs. This adds a runtime check that tracks which session first accessed the signal and throws a clear IllegalStateException with guidance if a different session accesses it later. ---------

• Automatic repeatable reads for shared signals while session is locked
  Commit · Pull request · Issue

  Shared signal reads within the same VaadinSession lock scope now get automatic repeatable-read guarantees via a session-scoped write-through transaction. This prevents race conditions where concurrent modifications to shared signals could cause multiple reads to return different values within a single request. The implementation adds a transaction fallback hook to SignalEnvironment that VaadinService wires up to lazily create a write-through transaction per lock/unlock cycle. The transaction is cleared on ultimate unlock. Local ValueSignal checks are updated to use inExplicitTransaction() so they remain usable when only the automatic session-scoped fallback is active (since it uses write-through semantics compatible with local signal state management).

Fixes

• Override get/peek/peekConfirmed with non-null return in collection-based signals
  Commit · Pull request · Issue

  The base classes explicitly annotate get(), peek(), and peekConfirmed() as Nullable, which overrides the NonNull type argument substitution in JSpecify semantics. Override these methods in ListSignal, SharedListSignal, SharedMapSignal, and SharedNumberSignal so that callers like listSignal.get().size() do not produce nullability warnings.

• Use raw request URI for baseHref calculation to support encoded slashes
  Commit · Pull request · Issue

  The previous fix for encoded slashes (%2F) in wildcard route parameters (commit b0c121b) set urlPathHelper.setUrlDecode(false) in ForwardingRequestWrapper, which made getPathInfo() return percent-encoded paths for all requests. This broke static resource serving for files with spaces in their names and potentially affected other getPathInfo() consumers like DAUUtils. Instead of disabling URL decoding globally, fix the actual site where the raw path matters: BootstrapHandlerHelper.getServiceUrl(). This method uses getCancelingRelativePath() to count path segments for the baseHref, which must use the raw URI so that %2F is not mistaken for a real path separator. The fix computes the raw path info by stripping the context path and servlet path from the request URI, preserving the original encoding. This allows reverting setUrlDecode(false) so that getPathInfo() returns properly decoded paths for all consumers.