swarm-controller: replay a subagent's newest rows before its live tail
A subagent's terminal opened directly showed nothing until the subagent published again: the relay was a core subscription, though its rows sit in term-sub-<agent> for 24 hours. It now goes through the agent route's replay-then-tail, so it opens with the subagent's newest 100 rows and resumes after Last-Event-ID. - term_stream.rs: the replay takes a stream name and a filter subject instead of an agent, and `replay_or_live` (replay, else the live core subscription) is the one fn both routes call. When the filter is one of several subjects in the stream, a fresh reader's consumer starts at the oldest row and drops all but the newest REPLAY_ROWS it counts as pending, since the stream's newest sequences may belong to sibling subagents. A single-subject stream (term-main-<agent>) picks its start with replay_start exactly as before. Tests for both subagent cases. - subagent_term.rs: the relay calls replay_or_live on the subagent's subject in term-sub-<agent> and reads Last-Event-ID; module doc and OpenAPI text no longer say "live only". - main.rs: the handler test passes the new headers argument. - swarm-queue-client agent_term.rs: replay_consumer_config takes the filter subject instead of the agent. - swarm-queue-client subagent_term.rs: consumer_create_grant, the extended CONSUMER.CREATE form with a subagent subject as filter. - swarm-nats-auth policy.rs: the controller holds that grant; the agent grant's `$SWARM.term.*` filter is two tokens short of a subagent subject, and the test that refused it now admits it. - docs/swarm/ui.md, README.md: a subagent terminal opens with its newest rows. Fixes #5527
This commit is contained in:
parent
f65364759f
commit
d9c586ef94
8 changed files with 272 additions and 71 deletions
|
|
@ -51,7 +51,7 @@ dimmed, as **not running**.
|
|||
|
||||
An agent's terminal opens with its last 100 rows from the past 24 hours, then
|
||||
follows new ones; a reconnect picks up after the last row it showed. A subagent
|
||||
terminal shows rows published while it's open, and has no turn-state badges.
|
||||
terminal does the same with that subagent's rows, and has no turn-state badges.
|
||||
|
||||
The settings menu in the header has a **hide debug output** toggle. It drops
|
||||
the muted debug rows (thinking, coalesced ticks, harness chatter) from every
|
||||
|
|
@ -256,7 +256,12 @@ or `null` when that row isn't read within two seconds. The lookups run
|
|||
concurrently, sixteen at a time, so the list waits at most two seconds for
|
||||
each sixteen subagents.
|
||||
swarm-controller also relays one subagent's rows as SSE on
|
||||
`GET /api/agents/<name>/subagents/<subagent>/term/stream`. An agent with no
|
||||
`GET /api/agents/<name>/subagents/<subagent>/term/stream`. Like the agent's
|
||||
terminal route below, it creates a short-lived consumer on that stream, here
|
||||
filtered to the one subagent, which sends its newest 100 rows and then each new
|
||||
one, with the same `Last-Event-ID` resume. The stream holds every subagent of
|
||||
the agent, so for a fresh reader the consumer starts at the oldest row and
|
||||
swarm-controller drops all but the newest 100 before sending. An agent with no
|
||||
store identity, or no queue address, publishes no subagent terminals.
|
||||
|
||||
</details>
|
||||
|
|
|
|||
Loading…
Reference in a new issue