feat: let one source carry several chats, and open them with a +
Nightly Build / build (push) Successful in 7m49s

A source had exactly one live conversation, so the copilot could only ever
replace a chat, never add one: the trash button reset the source and the old
conversation was left orphaned. Working on two things at once meant losing one.

The tab bar now holds two kinds of tab. A primary tab is a source — it shows
whatever `web` or `project-7` currently points at, which is where background
delivery lands (notify, a finished async task, an inbound Telegram message) and
what a reset moves to a fresh row. A secondary tab, opened with `+`, is one
specific conversation: its source points elsewhere, so it is unreachable by
source name and is addressed by id throughout — REST, WebSocket, event
filtering. `POST /api/sessions/new` creates one without touching `sources`,
which is the whole difference from a reset; its agent and run-context still come
from the source, so an extra project tab is the coordinator with the project's
context. Project "Open chat" is untouched and still resumes the project's own.

The load-bearing half is in ChatHub: the input queue and the model pin are now
keyed by session, not by source. Two tabs on one source would otherwise
serialize into a single queue and a single turn, and share a `/model` pin — the
odd one out, since the security group was already per-session and persisted. The
source-taking methods survive as one-line resolvers, so Telegram, mobile and
cron are untouched. Because queues now grow with conversations rather than with
the handful of sources, a reset retires the queue it replaces instead of leaving
a consumer task parked forever.

Events are filtered per conversation, so anything a chat must see has to carry a
session id: `show_file_to_user`'s OpenFile and the security-group revalidation
were emitting untagged and would have reached nobody. A primary connection
additionally follows NewSession for its source, so a second window does not keep
talking to a conversation another window just reset.

Tabs can be renamed by double-click — `chat_sessions.title` existed and was dead
until now. An empty name stores NULL, so the box is also the undo.
This commit is contained in:
2026-08-04 22:15:20 +01:00
parent 8f5c5382c8
commit 78cdcf4cc7
22 changed files with 1026 additions and 248 deletions
+32 -8
View File
@@ -1,9 +1,14 @@
//! Per-source input inbox for ChatHub.
//! Per-conversation input inbox for ChatHub.
//!
//! Each interactive source (telegram, web, mobile…) gets one `SourceInbox` and a
//! single consumer task (spawned lazily in `ChatHub`). A single consumer per
//! source makes delivery strictly FIFO, removing the ordering race of the old
//! detached-spawn dispatch.
//! Each conversation gets one `ConversationInbox` and a single consumer task
//! (spawned lazily in `ChatHub`). A single consumer per conversation makes
//! delivery strictly FIFO, removing the ordering race of the old detached-spawn
//! dispatch.
//!
//! The key is the **session**, not the source it answers on. A source used to be
//! close enough — it had exactly one live session — but the copilot can now hold
//! several conversations on the same source, and keying the queue by source would
//! serialize two of them into one turn on whichever session the source points at.
//!
//! Messages are kept as **individual** units — they are not coalesced here. The
//! consumer pops one to seed a turn (`build_unit`); any further messages that
@@ -17,7 +22,7 @@
//! `ChatSessionHandler.processing`; this inbox sits in front of it, adding ordering.
use std::collections::VecDeque;
use std::sync::atomic::AtomicU64;
use std::sync::atomic::{AtomicBool, AtomicU64, Ordering};
use tokio::sync::{Mutex, Notify};
@@ -30,14 +35,33 @@ pub(super) struct QueuedMessage {
pub opts: SendMessageOptions,
}
/// Pending queue + wake signal for a single source.
/// Pending queue + wake signal for a single conversation.
#[derive(Default)]
pub(super) struct SourceInbox {
pub(super) struct ConversationInbox {
pub pending: Mutex<VecDeque<QueuedMessage>>,
pub notify: Notify,
/// Bumped by `ChatHub::cancel` (after clearing `pending`) so the consumer can
/// drop a unit it drained microseconds before a `/stop`.
pub cancel_epoch: AtomicU64,
/// Set when the conversation this queue belongs to is gone for good (a reset
/// replaced it), so its consumer task stops instead of parking forever.
///
/// Keying queues by conversation rather than by source means their number
/// grows with conversations talked to since boot, not with the four or five
/// sources — so a queue that can never receive again has to be able to end.
closed: AtomicBool,
}
impl ConversationInbox {
/// Retire this queue and wake its consumer so it observes the flag.
pub fn close(&self) {
self.closed.store(true, Ordering::Release);
self.notify.notify_one();
}
pub fn is_closed(&self) -> bool {
self.closed.load(Ordering::Acquire)
}
}
/// Pops the next dispatch unit from `pending` — a **single** message, used by the