puter/paseo
1
0
Fork 0
mirror of https://github.com/getpaseo/paseo.git synced 2026-11-09 09:54:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

test(app): pin the held running turn across a freshness check

Browse Source 
A chat that left mid-turn holds its running footer until its messages are
current. With the freshness check, "current" is that commit with no rows, so
the tests and the timeline-sync doc now cover the check in flight, a current
answer, and a behind answer that holds until the fetched rows land.
This commit is contained in:
Mohamed Boudra
2026-11-09 09:53:55 +01:00
parent 279211e110
commit 130dec624d
2 changed files with 175 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/timeline-sync.md
+16 -13
View File
@@ -125,19 +125,22 @@ current. The timeline owner publishes freshness; the view renders it without a t
separate resume workflow.
The turn footer in a chat follows its messages, not the agent status. Turn activity comes from the
agent directory and messages from the chat's own catch-up, and either can land first. So the timeline
owner keeps an unsettled turn per chat: the turn its messages were captured during. It is set when a
catch-up becomes owed while the turn is open, or when cached messages are painted that were saved
while one was, and it is saved with those messages in the replica. It carries the turn's start time.
While it is set and the agent reads idle, the chat keeps showing that running turn, with its loader
and elapsed timer unchanged, and there is no separate catching-up footer. The commit that brings the
chat current clears it, in the same store write as the rows, so the final messages and the completed
footer land together. A failed catch-up clears it too, and the footer takes the true status. Losing
the connection is not a failed catch-up: none can run or fail until the host returns, so the running
footer stays beside "Reconnecting to host" and the catch-up on reconnect resolves it. Releasing it
offline would put a completed footer under messages known to be behind. Surfaces outside the timeline (the sidebar, tabs, the composer's stop and send controls) read the true status
and never see this state. Live delivery needs no hold because `applyStreamEvent` commits queued rows
before it applies turn liveness.
agent directory and messages from the chat's own catch-up, and either can land first. So the
timeline owner keeps an unsettled turn per chat: the turn its messages were captured during. It is
set when a check or catch-up becomes owed while the turn is open, or when cached messages are
painted that were saved while one was, and it is saved with those messages in the replica. It
carries the turn's start time. While it is set and the agent reads idle, the chat keeps showing that
running turn, with its loader and elapsed timer unchanged, and there is no separate catching-up
footer. The commit that brings the chat current clears it, in the same store write as the rows, so
the final messages and the completed footer land together. A `current` answer is that commit with no
rows. A check in flight keeps the hold, and `behind` keeps it until the fetched rows land. A failed
catch-up clears it too, and the footer takes the true status. Losing the connection is not a failed
catch-up: none can run or fail until the host returns, so the running footer stays beside
"Reconnecting to host" and the check on reconnect resolves it. Releasing it offline would put a
completed footer under messages known to be behind. Surfaces outside the timeline (the sidebar,
tabs, the composer's stop and send controls) read the true status and never see this state. Live
delivery needs no hold because `applyStreamEvent` commits queued rows before it applies turn
liveness.
The draft-create handoff has the same lifetime: the viewed-timeline owner releases it when the sync
stops owing that chat a catch-up, not when the first authoritative page lands. Releasing it at the