mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-11-04 19:28:46 +01:00
DottaandPaperclip
652cd76026
## Thinking Path > - Paperclip manages agents and their tasks. > - A native run can fail while it still owns a same-run retry. > - The server supports Stop for that pending execution. > - Run details show Cancel only for queued or running records. > - A failed pending retry therefore has no ordinary cleanup control. > - This pull request exposes the existing Stop eligibility and uses the existing cancellation endpoint. ## Linked Issues or Issue Description Refs #14743 and #14733 for correlated native Stop. Those changes cover backend cancellation and protocol qualification. They do not add the failed-run control to run details. Searches of current master and open PRs found no matching UI repair. **What happened?** A native run can show failed while its coordinator still owns a retryable failure with no accepted result. The backend can cancel that retry. Both run-detail implementations hide the cancellation button because the record is terminal. **Expected behavior** The selected run offers Stop when the server confirms that pending native retry. Unknown, legacy, terminal and accepted-result states do not gain this control. Existing queued and running cancellation stays available. **Steps to reproduce** Render either run-detail implementation for a failed native run with an eligible retry. The original UI has no Stop button. The original batched execution projection has no eligibility field. The regression tests exercise both real components and the actual PostgreSQL projection query. **Paperclip version or commit** The missing control and projection field were reproduced on44a4ca1c61. Fresh master8fd917aedfhas identical affected production blobs before this repair. **Deployment mode** Board run details for a native Runner task. Local verification uses rendered React components and PostgreSQL. No hosted task mutation or provider retry was performed. ## What Changed - Add optional `execution.canStop` to the existing batched projection. Read the matching retryable coordinator and absence of an accepted result. The cancellation endpoint remains the authority owner. Add no database queries. - Exclude Grok failed retries from the new hint and both consumers. The existing Grok Stop endpoint cannot accept a failed retry before assignment. Keep this limitation explicit and preserve its active-work authority checks. - Show Stop for eligible failed runs in both run-detail consumers. Keep the existing cancellation endpoint and its company, actor and row-lock checks. - Use the existing request-correlation contract for failed-native Stop. Persist one scoped identity before sending and recover it after remount or reload. Read a matching canonical claim only for the same board actor, company and run. Use the existing UUID fallback on ordinary HTTP. Never retry Stop automatically. Refresh the selected run and history after either outcome. - Report a stale conflict or a true no-op200 response. Accept a matching durable pending cancellation intent without requiring terminal acknowledgement. Keep running, queued and Grok calls unchanged. - Add actual rendered interaction tests, real batched-query controls and a short execution contract. Keep maps unchanged for this bug fix. ## Verification - Untouched UI and real Postgres producer reds cover missing Stop and missing eligibility. A valid Grok review found an unsupported failed-run action; actual broker, projection and rendered controls reproduce it before exclusion. No backend authority was expanded. - The original60-case focused suite passed, including26 rendered cases, the batched producer, and actual Grok broker/assignment fences. The related57-case scope passed before the Grok correction; it is not presented as final-head proof. - A fresh native4/5 review found a stale200 no-op. Both actual rendered consumers failed that new assertion. The real authenticated HTTP/Postgres fixture proves `canStop=true`, coordinator revocation, uncorrelated unchanged200 with a cancellation activity, and existing correlated409 with no new activity or run mutation. - The correlated repair passed82 affected cases before master reconciliation. Exact `74c60c9ffe11c05bc85f3d0fa5a136f7e9d445cd` passed80 rendered/API, HTTP and native-correlation cases. The render scope verifies request bodies, stable identity after an unknown outcome, no-op200 error, pending intent acceptance, wrong-run/request denial and existing active/Grok behavior. - Subsequent current-head reviews found remount identity loss and unavailable `crypto.randomUUID` on ordinary HTTP. The corrected helper passed 52 rendered cases across both consumers, including an unknown response, initial scoped storage persistence, a prior browser record with a unique never-mounted run identity, exact ID reuse, canonical claim recovery, actor switch, wrong run and HTTP UUID fallback. A real local-board identity mismatch was reproduced with two additional reds before using the actual server-projected actor ID. - Real authenticated HTTP and existing native-correlation suites passed 45 cases for canonical claim recovery and actor fences. Production UI, server and vendored Runner builds and all server/UI type layers passed at the prior reviewed helper head; exact final `e0f723b1c86f1529029bf141943323764de28c22` UI types, token gates and production build passed. - Fixture failures are retained separately: a missing local SDK build dependency, and a missing coordinator FK teardown in the new HTTP fixture. Neither is a behavior red. Both fixtures were corrected and the affected tests passed. - Previous-head3d CI required one diagnostic rerun after a Runner shutdown and a real account-list migration assertion. Two untouched157-test runs did not reproduce the assertion. Complete original row equality is unavailable. The assertion remains unresolved; no test was sorted, skipped or changed to green CI. - Previous-headf12 CI lost eight child runners. Its one authorized failed-job retry also lost e2e5 to an explicit shutdown. No second retry was issued. Those failures remain recorded. Current-head CI and both substantive reviews are required; older checks and grades are not credited. - Previous-head74c CI found a real monitor scheduler timeout. An untouched local replay and diagnostic-only replay reproduced it: the original manual-monitor run was still running at the unchanged three-second deadline. The cause remains unresolved; temporary diagnostics were removed, and no assertion, timeout or production monitor policy was changed. No CI retry was issued. - Exact local `906af5c942ee0963eb4b64552160b57a18bcd2d1` integrates normal master after #18930 merged. All reviewed Stop production and test blobs remain unchanged from `e0f723b1c86f1529029bf141943323764de28c22`. The four rendered, projection, HTTP and correlation files passed 99 cases after integration. All UI/server type layers, token gates and production UI/server/Runner builds passed at that exact head; the server build stamp records it. - Previous-head e0 CI reported a Discord ownership error. That original failure is preserved. Separate #18930 proves and repairs receiver construction/renewal races with the same error; the original CI scheduling order remains unproved. This branch now contains that ordinary master merge and requires fresh CI rather than rerunning the old failed attempt. - Full repository checks were not run locally for this narrow slice. No hosted task, provider execution or Stop receipt was created by this work. ## Risks Grok failed retries remain unsupported by this UI change. The existing Grok running and queued Stop action, revoke path and assignment fences are unchanged. A valid initial review caught the overbroad hint; actual broker, projection and rendered regressions reproduce it before correction. No backend cancellation authority was widened. The optional hint can become stale. It grants no permission. The existing cancellation path rechecks current authority and can reject the request. Run details show that rejection. Older servers omit the hint, so failed runs keep their existing behavior until the server updates. No retry, task hold, accepted-result decision or provider receipt is changed. ## Model Used OpenAI GPT-6.1 Sol (`gpt-6.1-sol`) in Codex, with source editing, terminal execution and tool use. The host did not report 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 - [ ] All Paperclip CI gates are green - [ ] 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>
@paperclipai/ui
Published static assets for the Paperclip board UI.
What gets published
The npm package contains the production build under dist/. It does not ship the UI source tree or workspace-only dependencies.
Storybook
Storybook config, stories, and fixtures live under ui/storybook/.
pnpm --filter @paperclipai/ui storybook
pnpm --filter @paperclipai/ui build-storybook
Typical use
Install the package, then serve or copy the built files from node_modules/@paperclipai/ui/dist.
Editor dependency identity
Keep the root and workspace overrides for @codemirror/state,
@codemirror/view, and @lezer/common aligned. CodeMirror requires shared
extension identity, while Lezer parsers and syntax highlighters require shared
NodeProp IDs. Multiple Lezer copies can crash code-block highlighting with
tags is not iterable. src/lib/codemirror-single-instance.test.ts checks the
installed dependency graph and highlights sample code through the editor's real
language dependencies. GitHub Actions owns regeneration of pnpm-lock.yaml.