2 Commits

Include renames

Author	SHA1	Message	Date
DottaandPaperclip	71c04c0bfb	fix: stop idle environment cleanup polling (#17145) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agent environments can leave pending teardown or unverified provider resources. > - Recovery must preserve those resources until ownership and workspace safety allow cleanup. > - Empty maintenance scans keep an idle instance and its database active. > - The existing rows, transaction signals, and scheduler can represent the actual recovery obligation. > - This pull request schedules pending cleanup and historical verification only while work remains. > - An empty or fully verified instance stops these scans without losing cleanup recovery. ## Linked Issues or Issue Description **What happened?** The server scanned pending environment cleanup on its maintenance tick. The run reaper also scanned it even when it recovered no runs or active leases. Historical resource verification scanned every five minutes, including when all history already had valid cleanup proof. **What did you expect?** Writes should wake cleanup. Pending rows, deferred orphan buffers, and unverified history should retain recovery deadlines. When none remain, these workers should make no periodic database or provider calls. **Steps to reproduce** Start a configured instance with no pending leases and fully verified history. Leave it idle. Observe repeated pending-cleanup and historical-verification reads from the maintenance paths. Related: #17106 supplies the preceding login-cleanup migration. #13523 improves lease-reaper query indexes. #16809 addresses reusable-sandbox recovery authority. This PR keeps those authority checks in their existing services. ## What Changed - Register two workers with the existing delivery coordinator and shared scheduler. Remove their unconditional maintenance-tick calls. Run the reaper's inline pending cleanup only after it recovers actual work. - Add commit-aware signals to the audited lease and custom-image writers. Existing transactions notify directly; other writers use one small transaction helper. No tables or migrations are added. - Derive pending cleanup deadlines from the existing row backoff and retry or claim metadata. Retain a historical retry only while an unverified candidate exists. - Register unwritten orphan buffers across runtimes that share the database handle. Buffer registration wakes recovery without a database connection. Load the existing spool at startup and retry failed or capacity-limited loads while needed. - Isolate spool failures per runtime. Attempt all buffers and persisted pending rows, then retain a retry for any failed spool. - Document producer coverage, idle behavior, and remaining blockers. Update the sleep inventory. - Repair the inherited CSS-recovery E2E test: the current build no longer emits task-page CSS. Exercise the actual lazy environment stylesheet, preserving real network failure, recovery, and bounded reload assertions. ## Verification October 24 integration update: merged current master and resolved the runtime/spool conflicts. Preserve serialized ingestion of records appended after startup. Plugin replacement failures now register deferred recovery with an idle hold; concurrent callers share one persistence attempt. The producer audit includes this new writer. - Focused cleanup selection: 270 tests now pass across five suites. The initial run lacked a built plugin SDK and executed no tests; building the SDK fixed setup. The new concurrent-flush assertion then reproduced duplicate rows; a single-flight guard fixed it and all 18 plugin integration tests passed on rerun. - Server typecheck passed. After review fixes, all 211 tests across the cleanup worker, real orphan spool, environment runtime, and plugin integration suites passed. These overlap the earlier focused selection. The rate-limit test initially expected a write after twenty idle minutes to wait; corrected it to assert that subsequent writes cannot accelerate the five-minute cadence. - Review fixes preserve retries for unreadable spool directories/records, keep historical provider checks off the startup wait while joining them at shutdown, and restore their independent five-minute minimum spacing. The complete [CI matrix](https://github.com/paperclipai/paperclip/actions/runs/40108905033) passed on final commit `79ae1589c3c7b924db4bedb337d0c7ed3d95020b`, including all E2E shards, server/workspace tests, runner checks, typecheck, build/public-install verification, and security checks. - CI found a stale E2E asset matcher: `issue-detail-*.css` is no longer emitted. Both corrected browser tests passed against a fresh production UI build and disposable local instance. Fresh Greptile review is 5/5 on that same final commit, with all review threads resolved. Previous implementation verification: - `pnpm -r typecheck` and `pnpm build` passed. - New PostgreSQL worker suite: 12 tests passed. Covers quiet configured state, verified history, writes, outer commit and rollback, retry deadlines, restart, drain, deferred orphan buffers, spool failure, pagination, provider uncertainty, shutdown, and the idle run-reaper path. - Worker and environment runtime suites after review fix: 183 tests passed. A new assertion reproduced buffer starvation before the fix. Updated transaction fault injection and isolated simulated-instance database handles. Server typecheck also passed after the fix. - Run-recovery suites: 58 tests passed. Pending-cleanup suite: 38 tests passed after updating the logging fixture to seed real orphan recovery; an idle reaper no longer invokes cleanup. - Stop and workspace-recovery integration selection: 268 tests passed; two live-provider tests skipped by their environment gate. This overlaps the worker suite and is not an additional unique-test count. - Started the full local `pnpm test:run`, then stopped that older duplicate run after CI found the fixture mismatch. The corrected 38-test suite passed locally. The full sharded [CI matrix](https://github.com/paperclipai/paperclip/actions/runs/39678174479) passed on final commit `fc0ff3c4554ca4190a8b0b81ec06ef7065b8ad2c`, including build, typecheck, runner, server, workspace, and E2E checks. This is not a claim that the local full run completed. ## Risks - Missing a future producer signal could delay discovery until restart. The producer audit is documented in `doc/idle-environment-cleanup.md`. Independent SQL writers and another server process are outside the existing process-local notification contract. - Historical candidates blocked by ownership or provider uncertainty keep a five-minute retry until they can be verified. Provider destruction, claim fencing, Stop retention, and workspace safety remain controlled by their existing services. - This does not remove orphan-active discovery or legacy shutdown settlement from run recovery. Active custom-image expiry is also still periodic. External wake coverage does not change. - Local tests prove these workers become quiet and recover. They do not establish deployed instance suspension or fleet cost savings. ## Model Used OpenAI Codex (GPT-6), with code execution and reasoning. The exact serving model ID and context size were not exposed. ## 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-24 09:04:49 -07:00
3 people	73526559b5	fix(ui): reload once when a lazy chunk or its CSS fails to load (#17349) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The board UI loads each page as a lazy chunk. Vite adds a preload step that also loads the CSS of the chunk. > - Staging error monitoring reported `Unable to preload CSS for …/assets/issue-detail-CIbQo9zW.css`. The same file name comes from the current build, so the CSS did not change. One request for the file failed for a short time. > - Vite rejects only the first import that asks for a failed file. Later imports skip that file. On a task page, the first import is the task-page prefetch, which ignores errors. The page then shows without its CSS. On other pages that share the CSS, such as Agents, the lazy route rejects and the route error boundary shows the error. > - Neither case recovers without a manual reload. This is a routine retry that the app can do safely, so the app must do it. > - This pull request reloads the page one time when a chunk or its CSS fails to load. A loop guard limits this to one reload in five minutes. > - The benefit is that a stale tab after a deploy, or one failed asset request, recovers without an error page, without missing styles, and without error-monitoring noise. An asset that stays broken still shows the error and still sends a report. ## Linked Issues or Issue Description **What happened?** A board page showed "This page hit an error" with `Unable to preload CSS for <origin>/assets/issue-detail-<hash>.css`. On a task page, the same failure gave no error message, but the page showed without its stylesheet. **Steps to reproduce** 1. Build the UI and start the server. 2. Make the first request for `/assets/issue-detail-*.css` fail. The new Playwright spec does this with `page.route(...).abort("failed")`. 3. Open `/<prefix>/agents`. The route error boundary shows "Unable to preload CSS". 4. Open `/<prefix>/issues/<id>`. The task shows, but the browser does not request the task CSS again. The page has no task-page CSS. **Expected behavior** The app recovers from a chunk or CSS load failure without user action. If the failure continues, the app shows the error one time, with no reload loop. **Environment** Hosted staging browser. The local build of current `master` reproduces it. I searched open and closed PRs for `preload`, `preloadError`, and `stale chunk`. I found no related PR. ## What Changed - `ui/src/lib/chunk-load-recovery.ts` (new): `isChunkLoadError` matches the Vite CSS preload error and the dynamic import errors from Chromium, Firefox, and WebKit. `reloadForChunkLoadError` reloads one time. A `sessionStorage` marker blocks a second reload for five minutes. After the first reload, later chunk errors in the same document are part of that reload, so they return "reloading" and do not show an error. Without `sessionStorage`, the function does not reload, because it cannot guard against a loop. `startChunkLoadRecovery` listens for `vite:preloadError`. It does not cancel the event, so the import still rejects as before. - `ui/src/main.tsx`: Starts the listener before the first render. The listener covers every import, including the task-page prefetch that ignores errors. - `RouteErrorBoundary` and `AppErrorBoundary`: While a recovery reload runs, they show a loading state. They do not show the error page and do not report to Sentry. Other errors work as before. - Tests: Vitest unit tests for the helper and both boundaries. A new Playwright spec, `tests/e2e/chunk-load-recovery.spec.ts`, runs against the real server and the built UI. ## Verification - `pnpm --filter @paperclipai/ui exec vitest run src/lib/chunk-load-recovery.test.ts src/components/RouteErrorBoundary.test.tsx src/components/AppErrorBoundary.test.tsx`: 21 tests pass. - Full UI Vitest suite: 793 files, 9,075 tests pass. - `pnpm --filter @paperclipai/ui typecheck` passes. `node scripts/check-token-gates.mjs` is clean. `node scripts/check-maps.mjs` passes. - `npx playwright test --config tests/e2e/playwright.config.ts chunk-load-recovery.spec.ts`: 3 tests pass. - Task page with one failed CSS request: one reload, the CSS loads, and the task shows. - Agents page with one failed CSS request: one reload, the CSS loads, and the page shows with no error page. - CSS that always fails: one reload, then the error page shows. There is no second reload. - Red proof: I ran the same spec with the `ui/src` changes removed (current `master` UI code). Both recovery tests fail. On Agents, the route error boundary shows `Unable to preload CSS for http://127.0.0.1:3199/assets/issue-detail-CIbQo9zW.css`. On the task page, the CSS is never requested again. - A failure I found and fixed during the work: my first version changed only the error boundaries. The task-page e2e case failed with that version, because the prefetch received the error and the boundary never saw it. The `vite:preloadError` listener fixes that case. All results above are from the final commit. - The spec blocks service workers, because Playwright page routes cannot see requests that a service worker sends. With a worker, a failed network request for an asset that is not cached also gives `Response.error()`. Thus the preload error is the same. ## Risks - A page can reload while a user is on it. This occurs only after a chunk or CSS load failure, and at most one time in five minutes per tab session. Without this change, that page already shows an error or shows without styles. Composer drafts use browser storage, so a reload keeps them. - A failure that recovers no longer sends a Sentry event. A failure that continues after the reload still sends one, so a broken deploy stays visible. - The error patterns match browser and Vite message prefixes. If a browser changes its message, that browser goes back to the current behavior: the error page and a report. - No API, schema, or server changes. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`) by Anthropic, run as a Paperclip agent through Claude Code with tool use (shell, file edits, Playwright, and Vitest). ## 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 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: devinfoley <139239+devinfoley@users.noreply.github.com>	2026-10-23 12:06:38 -07:00