perf(tauri): native desktop event transport with fast assistant streaming

[pascalandr]

Summary

Commit 1 — \perf(tauri): modularize native desktop event transport\

• replace the Tauri-side browser \EventSource\ path with a Rust-native SSE transport
• coalesce and batch desktop events before they enter the UI event pipeline
• move reconnect, auth/session setup, active-session targeting, and shutdown handling into the desktop transport layer
• add Rust test coverage for batching, coalescing, buffering, and flush behavior

Commit 2 — \perf(ui): add fast assistant streaming render path\

• add a lighter-weight path for assistant streaming updates to reduce reactive churn during live output
• separate lightweight streaming preview updates from heavier store-backed synchronization
• reduce UI update pressure with markdown throttling, event coalescing, scroll coalescing, and active-session tracking
• include the stop/idle state fixes required by the updated streaming flow

Validation

• cargo test -- desktop_event_transport
• px tsc --noEmit
• cargo tauri build
• runtime tested on Windows

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/23398482721

Artifacts expire in 7 days.
Artifacts: (none found on this run)

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/23398502150

Artifacts expire in 7 days.
Artifacts: (none found on this run)

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/23399446411

Artifacts expire in 7 days.
Artifacts: (none found on this run)

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/23401824896

Artifacts expire in 7 days.
Artifacts:

• pr-242-a3e768c36a4a3a34df9c243e78bdf25e431c4d80-electron-linux
• pr-242-a3e768c36a4a3a34df9c243e78bdf25e431c4d80-tauri-macos-arm64

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/23402541285

Artifacts expire in 7 days.
Artifacts: (none found on this run)

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/23410012218

Artifacts expire in 7 days.
Artifacts:

• pr-242-aa0b3203b5910e5459cd1362b184d3f529ecd67e-electron-linux-rpm
• pr-242-aa0b3203b5910e5459cd1362b184d3f529ecd67e-electron-linux

[pascalandr]

I’d be happy to get a critical review on whether this direction makes sense upstream.

[shantur]

Hey @pascalandr ,

How does this Tauri specific change effect electron and server UI?

[shantur]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[pascalandr]

Hey @pascalandr ,

How does this Tauri specific change effect electron and server UI?

Only commit 1 is Tauri-specific.
Electron and the browser/server UI still use the existing browser EventSource path; they do not use the Rust transport.

Commit 2 is intentionally cross-host: it optimizes how streaming updates are applied/rendered in the UI, so it should benefits Tauri, Electron, and the browser path alike.

[shantur]

Am I correct in understanding that each platform will be using their native EventSource path?

[pascalandr]

In this PR:

• Tauri switches to the nenw Rust-native transport
• Electron and the browser/server UI keep the existing browser EventSource path

So only the Tauri transport changes here. The UI-side streaming optimizations are host-agnostic and sit below that transport choice.

[shantur]

@pascalandr - I am sure this works well but the problem is I don't have experience with Rust / Tauri . I am more Java / Node person and the Tauri app is 100% maintained by AI and community. The only reason it came in because people wanted it so AI made it.

I can't maintain Tauri only features as I can't code review them and EventSource being a core part any changes on it I will be totally reliant on AI or community for it.
So from my point of view, I see these platform specific changes

• Are they necessary to support the platform?
• Are these platform specific features bringing something really valuable?
• Can we live without these features and have less code to maintain?
• What are the trade-offs to not use them?

Would you help me decide these please?

[pascalandr]

I see but TBH, the Rust/Tauri transport is the part I cared about most, because I use the Tauri client all day long.
But I do not have solid benchmark data yet, so I would not say this is needed for Tauri support. It is an optimization, not a requirement.
Are you looking for a community maintainer for the Tauri app before accepting this kind of change?

[shantur]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

• Also Read my comments and inform about possible knock-on effects on Electron and server.

[codenomadbot]

I reviewed the latest PR state as a gatekeeper review.

My understanding of the request: evaluate the current PR for regressions, better implementation options, and specifically call out any knock-on effects on Electron and the server/browser UI discussed in this thread.

Findings:

1. High: the new transport abstraction drops browser-side SSE ping/pong handling, which will regress Electron and the server/browser UI.

   • packages/ui/src/lib/server-events.ts:42-58 now calls connectWorkspaceEvents(...) without supplying onPing.
   • packages/ui/src/lib/event-transport.ts:24-30 still supports onPing, but only if the caller passes it through.
   • packages/ui/src/lib/api-client.ts:426-455 shows the browser EventSource path still emits codenomad.client.ping events.
   • packages/server/src/server/routes/events.ts:50-53,81-87 and packages/server/src/clients/connection-manager.ts:89-95 show those pings must be answered or the server times the client out after 45s.
   • packages/server/src/plugins/voice-mode.ts:16-29 shows at least one user-visible feature that depends on this connection tracking.
   • Before this PR, server-events.ts answered the ping by calling sendClientConnectionPong(...); that behavior is gone.
   • Result: Electron and the browser/server UI will silently lose their tracked client connection every ~45s on the browser EventSource path. That is exactly the cross-host knock-on effect your thread was asking about.

2. High: the Tauri reconnect path clears the active session target and never restores it unless the user changes tabs/sessions again.

   • packages/ui/src/lib/native/desktop-events.ts:138-149 calls desktop_events_stop whenever the JS-side connection disconnects.
   • packages/tauri-app/src-tauri/src/desktop_event_transport.rs:364-371 clears state.active_target inside stop().
   • packages/ui/src/lib/server-events.ts:74-89 disconnects the current transport on every reconnect cycle.
   • packages/ui/src/App.tsx:266-280 only sends desktop_events_set_active_session(...) when activeStreamTarget() changes, not after transport reconnect.
   • Result: after the first native transport reconnect, the Rust side forgets which session is active, so the active-session-specific fast path can silently degrade until the user manually changes selection again. For a performance PR, losing the optimization after the first reconnect is a real behavioral regression.

Knock-on effects by host:

• Commit 1 is still Tauri-only in intent, but it is not fully isolated operationally because the new shared transport abstraction in commit 2 regresses the browser EventSource path.
• Electron and the server/browser UI do not take the Rust transport, but they do take the new connectWorkspaceEvents / ServerEvents path. So they are directly exposed to finding 1.
• I did not find evidence that Electron/server pick up the Tauri-native batching/coalescing code itself. The cross-host risk is from the shared UI transport refactor, not from Rust code execution on those hosts.

Better implementation direction:

• Preserve ping/pong at the abstraction boundary. Either keep the pong logic in ServerEvents, or make the browser transport implementation own ping replies so callers cannot accidentally omit them.
• Split native transport teardown semantics into “temporary disconnect for reconnect” vs “full stop”, or keep active_target outside stop() so reconnects do not erase session targeting state.
• Given the maintainer comments in this thread: this Tauri transport is an optimization, not a platform requirement, and it adds a large Tauri/Rust maintenance surface around a core event path. I would want hard benchmark evidence plus a simpler failure/reconnect story before accepting that maintenance cost upstream.

Validation notes:

• I attempted cargo test --manifest-path packages/tauri-app/src-tauri/Cargo.toml desktop_event_transport, but it is blocked in this workspace by a missing packages/tauri-app/resources/server build resource.
• I attempted UI typechecking, but the workspace does not currently have the UI/server dependencies installed, so that check is not meaningful here.

Gatekeeper verdict: not merge-ready. Both findings above are blocking regressions, and one of them hits Electron/server directly.

--
Yours,
CodeNomadBot

[shantur]

I see but TBH, the Rust/Tauri transport is the part I cared about most, because I use the Tauri client all day long. But I do not have solid benchmark data yet, so I would not say this is needed for Tauri support. It is an optimization, not a requirement. Are you looking for a community maintainer for the Tauri app before accepting this kind of change?

As of now, I want to keep native ( Tauri / Electron ) features to the bare minimum as my current process is to implement features in web and server and expect them to run on both Electron / Tauri without any changes. This helps me a lot in ways

1. I don't have to test multiple platforms.
2. I dont have to worry changing one will break the other
3. I can be fairly confident on the changes.

I will need some time to work out what needs to be done for cases like this.
Community maintainers are good to have but currently my work on CodeNomad is what I do in my free time and waiting on features to be tested on different platforms by different maintainers might prove a bit slow.
I would surely love to have maintainers come and join but for the core product, not per platform.

I hope you understand.

[pascalandr]

When you says not have to test multiple "platforms" do you mean Tauri / Electron or Windows/linux/Macos ?