fix(flow-client): log the init failure hidden by the offline stub - #25731
Merged
Merged
Conversation
When the UI initialization request fails, the client assumes the connection was lost and replaces the view with the offline stub. The FlowUiInitializationError carries the HTTP status and body of the failed request, but it was caught and discarded, so the only symptom left was a missing UI. In an application without @pwa the stub resolves to no route, so the page ends up showing "Couldn't find route for 'offline-stub.html'" and the server error is nowhere to be found.
The two offline stub cases wrapped route.action() in try/finally only so a throwing case could not leak the replaced console.error into the cases that follow. One sinon.restore() in the existing hook covers every spy and stub in the file, which all use the default sandbox.
Artur-
approved these changes
Sep 15, 2026
|
Contributor
vaadin-bot
added a commit
that referenced
this pull request
Sep 15, 2026
…5731) (CP: 25.3) (#25733) This PR cherry-picks changes from the original PR #25731 to branch 25.3. --- #### Original PR description > ## Summary > When the Flow UI initialization request fails, the client shows the offline stub and used to throw the real error away. Now it logs that error first, so the HTTP status and response body of the failed request are visible in the browser console. > > ## What changed > **Behavior change:** the client now writes one `console.error` message when init fails and it falls back to the offline stub. This affects every user whose app hits a failed init request. Nothing else changes: the fallback to the offline stub and the `CONNECTION_LOST` state work exactly as before, and the already-offline path stays silent. Tests that assert on `console.error` output could see one extra message. > > Why this matters: the `FlowUiInitializationError` carries the status and body of the failed request, but it was caught and dropped. The only symptom left was a missing UI. In an app without `@PWA` the stub has no route, so the page just says `Couldn't find route for 'offline-stub.html'` and the real server error is nowhere to be seen. > > In the tests, the two offline stub cases stub `console.error`, and a `sinon.restore()` was added to the existing `afterEach` hook. All spies and stubs in the file use the default sandbox, so that one call restores them all and keeps a failing case from leaking a replaced `console.error` into later cases. > > ## Test summary > > | # | Status | What the test verifies | Why it matters | > |---|--------|------------------------|----------------| > | 1 | ✅ | When init fails with HTTP 500, the offline stub is shown **and** `console.error` is called exactly once with an `Error` whose message contains `500` and the response body `unable to connect` | This is the fix. If it regressed, a server-side init failure would again be invisible and look like a missing UI | > | 2 | ✅ | When navigation starts while already offline, the stub is shown and `console.error` is never called | Keeps the log meaningful: a message means a real init failure, not a normal offline navigation | > | 3 | ✅ | The stub still loads `./offline-stub.html`, hides the loading indicator, and `onBeforeEnter` / `onBeforeLeave` still return `undefined` | Confirms the logging did not change the existing fallback behavior | > > - `Flow.should show stub when navigating to server view and Flow initialization fails due to network error` — rows 1, 3 > - `Flow.should show stub when navigating to server view offline` — rows 2, 3 > - `Flow.afterEach` (hook, not a test) — adds `sinon.restore()` so a stubbed `console.error` cannot leak into later cases > > Left untested on purpose: the exact wording of the log message, since only the attached error object carries information a developer can act on. Co-authored-by: totally-not-ai[bot] <290682512+totally-not-ai[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When the Flow UI initialization request fails, the client shows the offline stub and used to throw the real error away. Now it logs that error first, so the HTTP status and response body of the failed request are visible in the browser console.
What changed
Behavior change: the client now writes one
console.errormessage when init fails and it falls back to the offline stub. This affects every user whose app hits a failed init request. Nothing else changes: the fallback to the offline stub and theCONNECTION_LOSTstate work exactly as before, and the already-offline path stays silent. Tests that assert onconsole.erroroutput could see one extra message.Why this matters: the
FlowUiInitializationErrorcarries the status and body of the failed request, but it was caught and dropped. The only symptom left was a missing UI. In an app without@PWAthe stub has no route, so the page just saysCouldn't find route for 'offline-stub.html'and the real server error is nowhere to be seen.In the tests, the two offline stub cases stub
console.error, and asinon.restore()was added to the existingafterEachhook. All spies and stubs in the file use the default sandbox, so that one call restores them all and keeps a failing case from leaking a replacedconsole.errorinto later cases.Test summary
console.erroris called exactly once with anErrorwhose message contains500and the response bodyunable to connectconsole.erroris never called./offline-stub.html, hides the loading indicator, andonBeforeEnter/onBeforeLeavestill returnundefinedFlow.should show stub when navigating to server view and Flow initialization fails due to network error— rows 1, 3Flow.should show stub when navigating to server view offline— rows 2, 3Flow.afterEach(hook, not a test) — addssinon.restore()so a stubbedconsole.errorcannot leak into later casesLeft untested on purpose: the exact wording of the log message, since only the attached error object carries information a developer can act on.