[ZEPPELIN-6742] Connect the AI Assistant frontend to conversation REST and WebSocket APIs by voidmatcha · Pull Request #5563 · apache/zeppelin

voidmatcha · 2026-10-09T01:29:21Z

What is this PR for?

Connect the Assistant frontend to the conversation REST and WebSocket APIs. The transport provides conversation creation and retrieval, message sending, and response delivery for the UI.

Server PR #5547 has merged. PR #5558 has merged. This PR still depends on UI contracts #5561; its temporary base contains those changes for review.

What type of PR is it?

Feature

Todos

Merge [ZEPPELIN-6733] Add AI assistant chat to notebooks (server-side) #5547
Merge [ZEPPELIN-6738] Upgrade React to 19 and fix shared host integration #5558
Merge [ZEPPELIN-6741] Define shared AI Assistant UI contracts and message history behavior #5561 before this PR
Rebase onto master, retarget this PR to master, and rerun CI before merging
Compare against the final API contract from server PR [ZEPPELIN-6733] Add AI assistant chat to notebooks (server-side) #5547
Confirm CI on the current PR head

What is the Jira issue?

ZEPPELIN-6742

How should this be tested?

Run from zeppelin-web-angular/:

npm run build-project:sdk
npm run typecheck:react
npm --prefix projects/zeppelin-react test -- src/entities/assistant/model/assistantTransport.spec.ts

Also verify the REST and WebSocket integration against the final API contract from server PR #5547.

Screenshots (if appropriate)

N/A

Questions:

Does the license files need to update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

voidmatcha · 2026-10-09T10:05:18Z

This PR connects the frontend to the conversation REST API and WebSocket run events.

The current diff is +1,527/-1 across four files. Excluding 869 lines in *.spec.* tests, the review diff is +658/-1. There is no lockfile change.

Server PR #5547 has merged. This PR still depends on #5558 and #5561, which are included in its temporary base for review. After those prerequisites merge, I will rebase and retarget the PR to master, then verify the final API contract and CI before merging. CI passes on the current PR head; I will rerun it after the final rebase.

miinhho

Transport-level review. I reproduced the reported sequences by loading the module and controlling HTTP responses and socket events. I have not verified them against a live server or the notebook UI. The authentication comment is a contract question, not a confirmed integration defect.

miinhho · 2026-10-11T07:14:13Z

+// ACKs belong to the connection, even if the note or conversation that sent the request has unmounted.
+const trackPendingRun = (socket: AssistantSocket, conversationId: string, tracking: RunTracking): PendingRun => {
+  const pending: PendingRun = { abandoned: false };
+  tracking.disconnected.delete(conversationId);


This removes the previous disconnected marker before the new request has been accepted.

I reproduced this sequence: run A starts, its connection closes, and a retry is sent without reloading history. When that retry receives run.failed with status 409, the transport reports idle, even though A's history has not been recovered. The failure message itself says the conversation is still answering.

This conflicts with the documented behavior of retaining the lost-connection state until history is reloaded. Please preserve that uncertainty when the retry is rejected, and cover the disconnect → retry → 409 sequence in a regression test.

Thanks for catching this. The disconnected state now remains until the retry is accepted by the server. I also added a regression test for disconnect -> retry -> 409.

Fixed in 7ad64ff.

miinhho · 2026-10-11T07:14:13Z

+        {},
+        onAuthError
+      );
+      if (!before && runs.disconnected.delete(conversationId)) notifyRunState(runs, conversationId);


A successful latest-page response clears the current disconnected marker without checking whether the request predates that disconnect.

I reproduced this with an accepted run: start getMessages(), delay its response, close the socket, then release the history response. The state changes from disconnected to idle, although no history request was started after the connection loss.

Please ensure that a request spanning a newer disconnect cannot clear that disconnect's recovery state, and add a regression test for this ordering.

Thanks for catching the race. A history response requested before a disconnect can no longer clear that disconnect state. I added a regression test for this response ordering as well.

Fixed in 6de3a98.

Keep the transport and sidebar shell independently buildable while both use the same SDK slot contract. Confidence: high Scope-risk: none Not-tested: full notebook runtime integration

seung-00 · 2026-10-16T12:18:18Z

    ...later,
-    content: [earlier.content, later.content].filter(Boolean).join('\n\n'),
-    ...(toolCalls.length ? { toolCalls } : {})
+    segments


These parts seem to conflict with the changes in #5561

Right, these overlapped with the segments changes in #5561. I aligned them with #5561 in 847784c and c83e5b0, and I'll rebase onto master and retarget after #5561 merges.

seung-00 · 2026-10-16T13:11:05Z

+  typeof value === 'object' && value !== null && 'body' in value ? value.body : value;
+
+/** Hands 401/405 to the host, which owns login redirects and logout. */
+export type AssistantAuthErrorHandler = (status: number, location: string | null) => void;


The server doesn’t provide a redirect location. I’d prefer to leave unimplemented features out of the contract. What do you think?

You're right. Nothing on the server sets Location on a 401: form auth redirects to /api/login with a 302 that fetch follows to a 405, and Kerberos returns a 401 with only WWW-Authenticate. I narrowed the handler to (status: number) => void and dropped location from the error in c83e5b0.

… errors

seung-00 · 2026-10-16T16:18:38Z

+  disconnected: Map<string, object>;
+  listeners: Map<string, Set<(state: AssistantRunState) => void>>;
+  stopTracking?: () => void;
+}


I wonder if we could simplify the per-conversation state tracking a bit. One concern is that a client-side timeout leaves pending and active intact. If no terminal event arrives and the WebSocket stays connected, the conversation could remain blocked.

Some of this complexity seems to come from sharing the notebook WebSocket, where events can keep arriving after the user leaves the view. A separate assistant WebSocket tied to the component lifecycle might simplify this eventually.

One approach we could consider for this PR, without changing the server, is:

Keep a single slot for the current request:
for example: : { conversationId, phase: 'pending' | 'running', runId? }
The server already rejects concurrent requests in the same conversation with 409. We could ignore events whose conversationId does not match the slot, and clear both the slot and its subscription when the component unmounts.

Track the remaining edge case separately:
A user sends hi in conversation C1, leaves the page, then returns to C1 and sends bye. An event from hi could arrive while the client is waiting for bye and be mistaken for its response.
The single-slot approach would not fully handle this timing-dependent case, but it seems unlikely to happen often. Could we open a separate issue for it and address it later?

Thanks, done in d853f7d. A run now keeps only its own { conversationId, phase, runId? }, drops events for other conversations, and releases its subscriptions when it ends, times out, the socket closes, or the consumer unmounts. The duplicate check is left to the server's 409, and the abandoned/disconnected tracking and the run-state subscription are gone. I'll drop 'disconnected' and subscribeRunState from the contract in #5561.

For 2, an issue sounds good. Two related cases share the cause and could go in it: retrying after a client timeout can hit the same mix-up, and after a reconnect the run's events stay bound to the old connection, so the answer only shows after a reload. Echoing a client request id in run.started/run.failed would let the client tell them apart even before a dedicated socket.

…read

voidmatcha changed the base branch from temp/seung-00/assistant-transport-base to branch-seung-00-assistant-transport-base-temp October 9, 2026 01:35

voidmatcha closed this Oct 9, 2026

voidmatcha reopened this Oct 9, 2026

voidmatcha mentioned this pull request Oct 9, 2026

AI Assistant - integrated frontend seung-00/zeppelin#1

Open

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch 2 times, most recently from 2aaa236 to b75de05 Compare October 9, 2026 09:09

voidmatcha changed the base branch from branch-seung-00-assistant-transport-base-temp to branch-seung-00-assistant-transport-clean-temp October 9, 2026 09:09

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch from b75de05 to c470802 Compare October 9, 2026 09:13

voidmatcha force-pushed the branch-seung-00-assistant-transport-clean-temp branch from b772a8d to 9f119fc Compare October 10, 2026 00:50

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch from 0c3b303 to c41de73 Compare October 10, 2026 00:50

voidmatcha force-pushed the branch-seung-00-assistant-transport-clean-temp branch from 9f119fc to b0b71a0 Compare October 10, 2026 08:27

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch from c41de73 to 3af8991 Compare October 10, 2026 08:27

voidmatcha force-pushed the branch-seung-00-assistant-transport-clean-temp branch from b0b71a0 to fc57755 Compare October 10, 2026 08:37

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch from 3af8991 to 3bcb8e2 Compare October 10, 2026 08:37

voidmatcha force-pushed the branch-seung-00-assistant-transport-clean-temp branch from fc57755 to 404c586 Compare October 10, 2026 13:40

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch from 3bcb8e2 to e3e2119 Compare October 10, 2026 13:40

voidmatcha force-pushed the branch-seung-00-assistant-transport-clean-temp branch from 404c586 to e345f98 Compare October 10, 2026 15:44

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch from e3e2119 to c221c82 Compare October 10, 2026 15:45

voidmatcha changed the title ~~[ZEPPELIN-6742] Connect the Assistant frontend to conversation REST and WebSocket APIs~~ [ZEPPELIN-6742] Connect the AI Assistant frontend to conversation REST and WebSocket APIs Oct 10, 2026

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch from c221c82 to e4880f9 Compare October 11, 2026 04:28

miinhho reviewed Oct 11, 2026

View reviewed changes

voidmatcha added 5 commits October 11, 2026 20:23

Connect assistant REST and WebSocket transport

6525d95

Clarify Assistant transport reactivation comment

a4be408

Share Assistant slot type with the sidebar shell

4210944

Keep the transport and sidebar shell independently buildable while both use the same SDK slot contract. Confidence: high Scope-risk: none Not-tested: full notebook runtime integration

Preserve Assistant disconnect state on rejected retries

7ad64ff

Ignore history responses older than an Assistant disconnect

6de3a98

voidmatcha force-pushed the branch-seung-00-assistant-transport-clean-temp branch from 7b16eb1 to 3e95adf Compare October 11, 2026 11:31

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch from e4880f9 to 6de3a98 Compare October 11, 2026 11:31

tbonelee mentioned this pull request Oct 15, 2026

[ZEPPELIN-6741] Define shared AI Assistant UI contracts and message history behavior #5561

Open

3 tasks done

voidmatcha added 2 commits October 15, 2026 23:30

Preserve Assistant history round order

908d8b6

Preserve Assistant rounds in conversation transport

d1e20dc

voidmatcha mentioned this pull request Oct 15, 2026

[ZEPPELIN-6733] Add AI assistant chat to notebooks (server-side) #5547

Merged

voidmatcha added 2 commits October 16, 2026 00:21

Consume segment-only assistant history contract

665a351

Align Assistant transport with server contract

a3acd8e

voidmatcha force-pushed the voidmatcha/assistant-v2-6-transport branch from 698542f to a3acd8e Compare October 15, 2026 15:43

[ZEPPELIN-6742] Block duplicate assistant sends during active runs

24dc652

seung-00 reviewed Oct 16, 2026

View reviewed changes

voidmatcha added 2 commits October 17, 2026 00:40

[ZEPPELIN-6742] Return merged Assistant answers explicitly

847784c

[ZEPPELIN-6742] Drop the unused redirect location from Assistant auth…

c83e5b0

… errors

seung-00 reviewed Oct 16, 2026

View reviewed changes

[ZEPPELIN-6742] Simplify Assistant run tracking to the request being …

d853f7d

…read

Navigation Menu

Repository navigation

[ZEPPELIN-6742] Connect the AI Assistant frontend to conversation REST and WebSocket APIs - #5563

[ZEPPELIN-6742] Connect the AI Assistant frontend to conversation REST and WebSocket APIs#5563
voidmatcha wants to merge 13 commits into
apache:branch-seung-00-assistant-transport-clean-tempfrom
voidmatcha:voidmatcha/assistant-v2-6-transport

voidmatcha commented Oct 9, 2026 •

edited

Loading

Uh oh!

voidmatcha commented Oct 9, 2026 •

edited

Loading

Uh oh!

miinhho left a comment •

edited

Loading

Uh oh!

miinhho Oct 11, 2026 •

edited

Loading

Uh oh!

voidmatcha Oct 11, 2026 •

edited

Loading

Uh oh!

miinhho Oct 11, 2026 •

edited

Loading

Uh oh!

voidmatcha Oct 11, 2026 •

edited

Loading

Uh oh!

seung-00 Oct 16, 2026

Uh oh!

voidmatcha Oct 16, 2026

Uh oh!

seung-00 Oct 16, 2026

Uh oh!

voidmatcha Oct 16, 2026

Uh oh!

seung-00 Oct 16, 2026 •

edited

Loading

Uh oh!

voidmatcha Oct 16, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

voidmatcha commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is this PR for?

What type of PR is it?

Todos

What is the Jira issue?

How should this be tested?

Screenshots (if appropriate)

Questions:

Uh oh!

voidmatcha commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

miinhho left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

miinhho Oct 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

voidmatcha Oct 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

miinhho Oct 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

voidmatcha Oct 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seung-00 Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

voidmatcha Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

seung-00 Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

voidmatcha Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

seung-00 Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

voidmatcha Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

voidmatcha commented Oct 9, 2026 •

edited

Loading

voidmatcha commented Oct 9, 2026 •

edited

Loading

miinhho left a comment •

edited

Loading

miinhho Oct 11, 2026 •

edited

Loading

voidmatcha Oct 11, 2026 •

edited

Loading

miinhho Oct 11, 2026 •

edited

Loading

voidmatcha Oct 11, 2026 •

edited

Loading

seung-00 Oct 16, 2026 •

edited

Loading