[ZEPPELIN-6423] Reload note when switching notebooks in the Angular UI#5259
Merged
tbonelee merged 1 commit intoJun 2, 2026
Merged
Conversation
Member
|
@tbonelee Could you please rebase it? |
The note fetch was bound only to the WebSocket connectedStatus$ stream. Navigating between notes reuses NotebookComponent (ngOnInit does not re-run) and keeps the socket connected, so selecting another note from the header list changed the URL but never re-fetched the note - the page kept showing the previously loaded note. Drive the fetch from a combineLatest of the connection status and the route params so it fires on both WebSocket (re)connect and noteId/revisionId changes, preserving the reconnect-reload behaviour from ZEPPELIN-6387. Add an e2e regression test that opens one note and navigates to another via the header notebook list, asserting the displayed note content updates and not just the URL. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Assisted-By: Claude <noreply@anthropic.com>
40df07d to
eff8d6b
Compare
jongyoul
approved these changes
Jun 2, 2026
tbonelee
added a commit
that referenced
this pull request
Jun 2, 2026
Navigating between notes in the Angular UI changed the URL but left the page showing the previously opened note. The note fetch in `NotebookComponent` was bound only to the WebSocket `connectedStatus$` stream (introduced in ZEPPELIN-6387). Because Angular reuses `NotebookComponent` across `:noteId` route changes — so `ngOnInit` does not re-run — and the WebSocket stays connected, selecting another note from the header notebook list never re-fetched the note. The URL/route params updated, but `getNote()` was never called for the new `noteId`, so the page kept rendering the old note. This PR drives the fetch from a `combineLatest` of the connection status and the route params, so it fires on **both** a WebSocket (re)connect **and** a `noteId`/`revisionId` change. The reconnect-reload behavior from ZEPPELIN-6387 is preserved; `distinctUntilChanged` on the connection stream avoids a redundant fetch on init. Bug Fix * [x] Re-fetch the note on `noteId`/`revisionId` route changes * [x] Preserve WebSocket reconnect-reload behavior * [x] Add e2e regression test * https://issues.apache.org/jira/browse/ZEPPELIN-6423 * **Automated:** `zeppelin-web-angular/e2e/tests/notebook/main/notebook-navigation.spec.ts` opens one note, then navigates to a second note via the header "Notebook" dropdown and asserts the displayed note title (not just the URL) updates. Verified failing before the fix and passing after, against a live backend. * **Manual:** 1. Open a notebook. 2. From the header **Notebook** dropdown, click a different note. 3. The page content should switch to the newly selected note (previously it stayed on the old note while the URL changed). N/A * Does the license files need to update? No * Is there breaking changes for older versions? No * Does this needs documentation? No Closes #5259 from tbonelee/fix/notebook-reload-on-note-switch. Signed-off-by: ChanHo Lee <chanholee@apache.org> (cherry picked from commit 1d471c6) Signed-off-by: ChanHo Lee <chanholee@apache.org>
Contributor
Author
|
Merged into master and branch-0.12 |
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
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.
What is this PR for?
Navigating between notes in the Angular UI changed the URL but left the page showing the previously opened note.
The note fetch in
NotebookComponentwas bound only to the WebSocketconnectedStatus$stream (introduced in ZEPPELIN-6387). Because Angular reusesNotebookComponentacross:noteIdroute changes — songOnInitdoes not re-run — and the WebSocket stays connected, selecting another note from the header notebook list never re-fetched the note. The URL/route params updated, butgetNote()was never called for the newnoteId, so the page kept rendering the old note.This PR drives the fetch from a
combineLatestof the connection status and the route params, so it fires on both a WebSocket (re)connect and anoteId/revisionIdchange. The reconnect-reload behavior from ZEPPELIN-6387 is preserved;distinctUntilChangedon the connection stream avoids a redundant fetch on init.What type of PR is it?
Bug Fix
Todos
noteId/revisionIdroute changesWhat is the Jira issue?
How should this be tested?
zeppelin-web-angular/e2e/tests/notebook/main/notebook-navigation.spec.tsopens one note, then navigates to a second note via the header "Notebook" dropdown and asserts the displayed note title (not just the URL) updates. Verified failing before the fix and passing after, against a live backend.Screenshots (if appropriate)
N/A
Questions: