feat: let one source carry several chats, and open them with a +
Nightly Build / build (push) Successful in 7m49s
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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user