Files
PaperClipAI/maps/feature-map/steering.md
T
Devin FoleyandPaperclip 63fbb714e6 fix(server): release idle tracking after aborted static UI files (#16685)
## 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>
2026-10-17 20:28:57 -07:00

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)