mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-21 16:27:18 +02:00
## Thinking Path > - Paperclip runs work for AI agents. > - Hosts must prove that accepted work has finished before idle sleep. > - HTTP request tracking keeps unfinished writes active after a client leaves. > - Static file middleware has no returned completion promise. > - An aborted UI download can leave its request active forever. > - This PR completes only a matched file response and keeps other work tracked. ## Linked Issues or Issue Description Refs #15522. Found while qualifying #16679. A search found no duplicate static-download idle fix. **What happened?** Closing a client during a static UI download leaves one tracked request active. The response has closed, but the file middleware never calls the wrapped response end method. The instance cannot report idle after that request. **Expected behavior** A closed, matched static file response must not leave a permanent work hold. Unfinished application writes must remain tracked. A missing file must keep the normal fallback and error paths. **Steps to reproduce** 1. Serve a large local file through the static UI middleware with idle admission enabled. 2. Start the download over HTTP. 3. Disconnect the client after its first data chunk. 4. Observe that the tracked request remains active with the original middleware. **Paperclip version or commit** Reproduced on the behavior in `d30648dee89720358271c276b9fc28cf83f18be7`. This branch starts at `cfa9dce295970a85b3d8ee14cab0eccf50bc72e2`. ## What Changed - Mark the completion of a known read-only response without dropping pending middleware promises. - Wrap static UI file serving. A successful file match is required before a closed response can complete its tracking. A late match rechecks an already closed response. Missing files keep the normal fallback. - Use the wrapper for hashed assets, other static UI files, and public development files. Preserve caller headers and cache options. - Test both HTTP abort timings, nested routers, conservative mounted-application holds, parent writes, mutating GET fallbacks, and callback-only work. - Update the idle contract and its verification map. Correct the paused-message recipe from hosted qualification: an explicit Pause cancels older queued work, so test new accepted input after the pause and await the normal resume lifecycle. ## Verification - The original two real stream-abort regressions fail with the original Express static behavior. - Three review regressions fail on `e260f4694afab8447b0cb203f439cb3ccad254e8`: a client closing before file lookup, an unfinished parent in a mounted application, and an unfinished parent in a root without installed handler tracking. Fixed sources were restored byte for byte after the comparison. - Two focused suites: 16 passed. They cover nested routers, both abort timings, hidden parent writes, late missing-file fallbacks, contents, HEAD, conditional responses, and caller headers. - Module and map checks pass. Map checks are structural only. - `pnpm -r typecheck` and `pnpm build`: passed on `f242ee739344484995d3addf81635512370778c8`. - Full CI matrix: 54 successful checks and 2 intentional Storybook skips. - Apex: 5/5 on the exact current head, with zero unresolved threads. - Full local maintained test groups are still running before final handoff. - The initial local broad run was stopped before changing source for the P1 review findings. Two file-mode fixture failures in that run came from the scratch runner's inherited `0077` mask; the same suite passes with the normal child test mask `0022`, without source or host configuration changes. The replacement run uses `0022` for test children and command-scoped `init.defaultBranch=master` for existing Git fixture assumptions. - This PR has not been deployed to a hosted environment. ## Risks Only a matched file served by the admitted application with installed handler tracking can complete this way. Routers share that scope. Mounted Express applications and roots without handler tracking keep the existing conservative response hold; this change does not claim their hidden writes are tracked. An unfinished tracked parent promise still blocks sleep after a file client disconnects. Redirects, missing files, application callbacks, and other GET requests retain their guards. No authentication, company scope, provider cleanup, or scheduling gate is removed. No schema or API response changes. ## Model Used OpenAI GPT-6 through Codex, with reasoning, source editing, and shell tools. The session does not expose a more specific serving model ID or its context window size. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
179 lines
10 KiB
Markdown
179 lines
10 KiB
Markdown
---
|
|
navigation: {"section":"Tasks and conversations","sectionOrder":20,"order":60}
|
|
---
|
|
|
|
# Steering and queued messages
|
|
|
|
People can send follow-ups while an agent works, manage saved messages that have
|
|
not been consumed, and choose when to steer or interrupt. Stopping a run and
|
|
pausing a task are separate controls. The UI must preserve the message, explain
|
|
why it is waiting, and only claim delivery after an authoritative acknowledgement.
|
|
|
|
Agent access: [companion](../agent-access-map/steering.md).
|
|
|
|
## Sub-features
|
|
|
|
- `queue`: a busy task saves follow-ups and shows their order and wait reason.
|
|
- `edit-order-discard`: edit full Markdown, reorder, and discard eligible saved
|
|
messages; ownership, revision conflicts, and already-dispatched states matter.
|
|
- `steer`: explicit user action sends a queued message into a compatible active
|
|
run; unavailable capabilities and provider rejection remain visible.
|
|
- `interrupt`: stop the current execution and carry accepted follow-ups into
|
|
the eligible continuation without delivering them twice.
|
|
- `stop-and-pause`: distinguish stop-in-flight, confirmed stop, task/ancestor
|
|
pause, agent pause, and budget hold. Resume must respect the actual gate.
|
|
- `drafts`: switching tasks, reloading, and uncertain submission retain the
|
|
correct task's draft and attachment receipts.
|
|
- `approval-queue`: answered questions and accepted approvals have durable
|
|
delivery distinct from editable ordinary comments.
|
|
|
|
## How to get to it (user POV)
|
|
|
|
### `task-composer`
|
|
|
|
Open an assigned task (`/issues/:issueId`). Start work, then send follow-ups while
|
|
the agent runs. Use the queued-message controls to edit, reorder, discard,
|
|
steer, or interrupt when offered. Use the composer stop/pause control separately.
|
|
Both task presentations need attention when changing their shared behavior.
|
|
|
|
### `agent-chat`
|
|
|
|
Enable Agent Chat and open an agent conversation. Send another message during
|
|
a reply and inspect the shared queue. `/new` starts fresh provider context in
|
|
the same conversation; it is an ordered boundary, not a normal model prompt.
|
|
|
|
### `request-response`
|
|
|
|
Answer an earlier question or accept a confirmation while successor work is
|
|
active on the task. Inspect the resulting queued response and its available
|
|
steer/interrupt control instead of assuming acceptance interrupted execution.
|
|
|
|
### `external-channel`
|
|
|
|
Send a follow-up from a linked external chat conversation while its task is
|
|
running. Use that provider's supported stop/control affordance where available;
|
|
inspect the resulting task and run in Paperclip.
|
|
|
|
## Driving it
|
|
|
|
Preconditions: follow the [baseline](./README.md#before-driving-a-journey).
|
|
Use an agent that stays busy long enough to inspect the queue. Record the adapter,
|
|
native/legacy mode, and advertised steering capability. Test supported and
|
|
unsupported steering without treating an absent capability as a product failure.
|
|
|
|
### `task-composer`
|
|
|
|
Automated: [queued-message UI](../../ui/src/components/task-chat/TaskChatQueuedMessages.test.tsx)
|
|
covers order, failure restoration, unavailable steering, stale revisions, and
|
|
discard acknowledgements. [Queue routes](../../server/src/__tests__/issue-queued-comments-routes.test.ts)
|
|
cover durable ordering, authorization, steering acknowledgements, interrupt
|
|
recovery, and concurrent dispatch. [Composer](../../ui/src/components/task-chat/TaskChatComposer.test.tsx)
|
|
covers drafts and uncertain saves.
|
|
|
|
[Task-detail delivery races](../../ui/src/pages/IssueDetail.test.tsx) cover a
|
|
consumed message whose send response and queue snapshot arrive late. A started
|
|
run's input receipt removes that message from pending, while a separate unsent
|
|
message stays queued. Admission to a run that has not started is not delivery.
|
|
A later retry of the same message remains visible in its new authoritative queue.
|
|
Receipts retain the primary wake and coalesced source queue IDs. They clear a late
|
|
snapshot even when its target names the preceding run or is null.
|
|
|
|
```sh
|
|
pnpm exec vitest run ui/src/components/task-chat/TaskChatQueuedMessages.test.tsx server/src/__tests__/issue-queued-comments-routes.test.ts
|
|
```
|
|
|
|
Automated stop coverage is separate:
|
|
[composer stop](../../tests/e2e/composer-stop.spec.ts) with
|
|
[its configuration](../../tests/e2e/playwright-composer-stop.config.ts) and
|
|
[ACP stop/continuation](../../tests/e2e/acp-stop-continuation.spec.ts). Inspect their
|
|
fixture and opt-in prerequisites; skipped native cases are not native proof.
|
|
|
|
Manual: queue three distinguishable messages. Edit one, reorder them, reload,
|
|
and confirm the saved order. Discard one and confirm it never reaches execution.
|
|
After a queued message enters a started run, confirm it leaves pending even if
|
|
the send response arrives later. Reload and confirm it appears once in history.
|
|
Steer one while busy and verify the agent receives that exact message once.
|
|
Repeat with a rejected steer and a stale second-tab edit; the UI must preserve
|
|
retryable content and explain the conflict. On a fresh run, interrupt with a
|
|
queued follow-up and verify confirmed stop followed by one continuation. Pause
|
|
the task (and separately its ancestor), preserve a draft, then resume the actual
|
|
hold; no hidden send should occur while paused. Check both task presentations
|
|
when available; the named component tests do not prove every host integration.
|
|
|
|
Fixture-backed recovery check: start with an agent in its completed paused
|
|
lifecycle state, then insert a new accepted `deferred_issue_execution` request
|
|
through the [PostgreSQL recovery fixture](../../server/src/modules/wake-queue/adapters/postgres.test.ts).
|
|
Normal wake admission
|
|
rejects paused agents, so this pending state cannot be created by sending a new
|
|
message through the ordinary UI or API. Let release and periodic recovery run.
|
|
Confirm that the saved request remains pending. Resume the agent, wait for its
|
|
lifecycle to become ready, and verify one delivery. An explicit Pause cancels
|
|
older queued work; those cancelled receipts must not be replayed. A paused
|
|
request must not prevent another eligible recipient's queued work from proceeding.
|
|
|
|
### `agent-chat`
|
|
|
|
Automated: [agent chat sessions](../../tests/e2e/agent-chat-sessions.spec.ts) covers
|
|
persistent conversation/session behavior with deterministic harness fixtures;
|
|
shared composer tests cover the controls. These do not qualify live steering
|
|
for every harness.
|
|
|
|
Manual: queue two follow-ups while the conversation replies. Reload, edit or
|
|
discard one, then let the other run. Verify one reply and unchanged conversation
|
|
identity. Send `/new`, then a new prompt; old history remains visible, and the
|
|
new turn uses fresh provider context. Verify a useful answer rather than only
|
|
the session-divider UI. Repeat the queue operations with a live capable harness
|
|
when the change touches delivery.
|
|
|
|
### `request-response`
|
|
|
|
Automated: [response delivery](../../server/src/__tests__/question-response-delivery.test.ts)
|
|
proves queueing/coalescing and retry-safe receipts. The queue-route suite tests
|
|
separate comment and approval queues, explicit steering, and fresh-session
|
|
restrictions on plan approvals.
|
|
|
|
Manual: answer an old question during a new run, confirm that it is saved and
|
|
queued, and let the active run end. Verify exactly one continuation with the
|
|
answer. Repeat an eligible approval with explicit steer; another approval that
|
|
requires a fresh session must not offer same-turn delivery. Do not edit an
|
|
approval outcome through an ordinary queued-message editor.
|
|
|
|
### `external-channel`
|
|
|
|
Automated: [chat interaction arbitration](../../server/src/services/chat-interaction-arbitration.test.ts)
|
|
covers backend arbitration with simulated requests. It is not a provider UI test.
|
|
|
|
Manual: send two distinguishable messages through one disposable linked
|
|
conversation while busy. Inspect their saved task order, run delivery, and
|
|
external reply. Check a duplicate provider event and unauthorized sender.
|
|
Provider-specific control semantics and real transport timing remain a manual
|
|
gap; do not assume browser queue controls are available in every channel.
|
|
|
|
## Gotchas
|
|
|
|
- Paperclip's queue is server-owned once saved; it is not Omnigent's unsent
|
|
browser draft buffer. A stale edit must not overwrite a consumed message.
|
|
- Steer availability depends on the active runtime's capability, not its brand
|
|
name. A UI row disappearing optimistically does not prove provider receipt.
|
|
- Interrupt, stop, task pause, agent pause, and budget pause have different
|
|
effects. A running indicator disappearing does not prove remote work stopped.
|
|
- An interrupted run may need verified cleanup before a saved follow-up can
|
|
start. Preserve and inspect the wait reason; see [recovery](./recovery.md).
|
|
- A healthy idle Agent Chat is waiting for input, not stranded unfinished work.
|
|
|
|
### Storybook verification
|
|
|
|
#### `drafts`
|
|
|
|
Scope: ui
|
|
Storybook: Task-keyed restored draft and attachment receipts; task switch/reload, failed send and uncertain-save recovery.
|
|
Production: Retain correct task draft across navigation and reload; inspect authoritative saved receipt before claiming delivery; do not clear storage on every harness mount.
|
|
Sources: Source: [TaskChatComposer.tsx](../../ui/src/components/task-chat/TaskChatComposer.tsx), [composer-draft.ts](../../ui/src/lib/composer-draft.ts). Tests: [TaskChatComposer.test.tsx](../../ui/src/components/task-chat/TaskChatComposer.test.tsx), [issue-queued-comments-routes.test.ts](../../server/src/__tests__/issue-queued-comments-routes.test.ts)
|
|
|
|
#### `approval-queue`
|
|
|
|
Scope: ui
|
|
Storybook: Answered question/accepted approval delivery waiting, eligible steer/interrupt, failed delivery and fresh-session-only approval.
|
|
Production: Keep response delivery durable and distinct from editable comments; coalesce once, enforce fresh-session restrictions and deduplicate concurrent/retried continuation.
|
|
Sources: Source: [TaskChatQueuedMessages.tsx](../../ui/src/components/task-chat/TaskChatQueuedMessages.tsx), [question-response-delivery.ts](../../server/src/services/question-response-delivery.ts). Tests: [TaskChatQueuedMessages.test.tsx](../../ui/src/components/task-chat/TaskChatQueuedMessages.test.tsx), [question-response-delivery.test.ts](../../server/src/__tests__/question-response-delivery.test.ts), [issue-queued-comments-routes.test.ts](../../server/src/__tests__/issue-queued-comments-routes.test.ts)
|