Commit Graph
5 Commits
Author SHA1 Message Date
DottaandPaperclip 813e808af4 Remove filesystem history authorization from workspace preparation (#16963)
Remove physical-root source/reader authorization and sticky directory classifications from workspace preparation. Preserve current task/run authority, app-record privacy, credential authorization, containment, and lifecycle/publication integrity.

Validate replacement selections against persisted new inputs and refresh verified checkout ownership so bounded reuse survives earlier workspace relocation. Add real PostgreSQL/Git regressions, a reproducible history-scaling benchmark, and documentation.

Full CI passed all 48 jobs and Greptile scored 5/5 at 3d5da6c259. Five preparation-guard medians improved from 20,512.99 ms to 52.22 ms on the 8,500-workspace fixture; these are not end-to-end startup timings.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-20 09:19:59 -05:00
DottaandPaperclip cde944ed75 fix(workspaces): keep retained readers valid after cross-task wake coalescing (#16928)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Before a run starts, repository admission checks every retained
reader of the physical repository root and of overlapping roots.
> - Each retained reader records the run, task, agent and responsible
user that the server admitted.
> - A wake for another task can coalesce into a running run. The merge
replaces `contextSnapshot.issueId` and `taskId` with the other task.
> - The retained-reader check used that mutable context task before the
run's immutable task binding. The old reader then looked like a changed
identity.
> - When a later run admits an overlapping root, such as a shared
project checkout that contains earlier task worktrees, every admission
on that root fails. The root stays blocked and no operator action can
repair it.
> - This pull request accepts a retained reader when its task matches
the run's immutable binding or its current context task.
> - The benefit is that legitimate wake coalescing no longer blocks a
shared root, and missing or truly mismatched identities still fail
closed.

## Linked Issues or Issue Description

Refs #16717 and #16832. Those cover retained readers whose run, agent or
task was deleted. This pull request covers a different cause: every
identity still exists, but wake coalescing changed the run's context
task. #16832 keeps identity mismatches fail-closed, so it does not fix
this case. Both pull requests change the same condition in
`execution-workspace-root-readers.ts`. The pull request that merges
second must rebase.

**What happened?**
A scheduled routine run failed in setup with `Repository root retains a
reader whose identity is no longer available` (403). Every later run of
the routine failed in the same way, for eight hours in a row. Two
earlier runs of the same agent were the retained readers. Each run
started for its own task and recorded its reader. About 10 to 16 minutes
later, a monitor wake for a different task coalesced into the running
run with reason `issue_execution_same_name`.
`mergeCoalescedContextSnapshot` set `contextSnapshot.issueId` to the
other task. `heartbeat_runs.issue_id` stayed on the original task,
because the `heartbeat_runs_set_scope_kind` trigger makes the binding
immutable. The readers were on per-task worktree roots, so nothing
failed at first. Then the routine's tasks changed to the shared project
checkout. That root contains those worktrees, so admission loaded the
two readers, compared them with the changed context task, and threw.

**Expected behavior**
A retained reader stays valid while its run, agent, task and responsible
user still exist and still match what the server admitted. A context
change from wake coalescing must not make the reader unavailable. A
reader whose task matches neither the run's binding nor its context must
still be rejected.

**Steps to reproduce**
1. Admit run R for task A on a nested root, for example
`<checkout>/.paperclip/worktrees/a`.
2. Coalesce a wake for task B into R. `contextSnapshot.issueId` becomes
B. `heartbeat_runs.issue_id` stays A.
3. Admit or publish another task on the parent root `<checkout>`.
4. Observe the 403 `Repository root retains a reader whose identity is
no longer available`. Every later admission on that root fails in the
same way.

**Paperclip version or commit**
Reproduced on `master` at b44871098 with the new regression test.

## What Changed

- Add `runRetainsIssueIdentity(run, issueId)` in
`server/src/services/execution-workspace-root-readers.ts`. It accepts
the previous derived identity (`nativeIssueId ?? context issueId ??
context taskId ?? issueId`) or the immutable binding (`nativeIssueId ??
issueId`).
- Use the helper for the three retained-run identity checks:
`loadRepositoryRootReaders`, `requiresAnonymousRepositoryAcquisition`
and `assertRootProjectTrust`.
- Add a real PostgreSQL regression. A reader on a nested worktree root
is admitted for task A. The test builds the coalesced context with the
real `mergeCoalescedContextSnapshot`. Publication on the parent root
must succeed. A reader whose task matches neither the binding nor the
context must still fail.
- Move one existing row. The old "rejects" test changed only the context
task, which is now the legitimate coalescing case. The test now changes
the reader's recorded task to a different existing task, so the mismatch
path still fails closed.
- Update the retained-reader contract in `doc/DATABASE.md`.

## Verification

- Red before the fix: `pnpm exec vitest run --project
@paperclipai/server --maxWorkers=1 --fileParallelism=false
server/src/__tests__/repository-root-reader-queries.test.ts` fails 1 of
9 tests. The new test passes its first publication. It fails after the
coalesced context with `Repository root retains a reader whose identity
is no longer available` (403), which is the production error.
- Green after the fix: the same command passes 9 of 9 tests.
- One intermediate attempt failed and is kept here. My first test draft
changed `heartbeat_runs.issue_id`. The database trigger rejected it with
`run task binding is immutable`. That rejection confirms the binding
this fix relies on. The final test uses a separate run for the negative
case.
- Related suites: `task-workspace-repositories*.test.ts`,
`task-workspace-source-copy-privacy.test.ts`,
`project-workspace-root-provenance.test.ts`,
`workspace-authorization-query.test.ts`,
`execution-transaction-timing.test.ts`,
`execution-workspace-reopen.test.ts`, `file-resources.test.ts`,
`heartbeat-project-repositories.test.ts`,
`heartbeat-workspace-source-trust.test.ts` and
`heartbeat/workspace-preparation.test.ts`. All 13 files pass on the
fixed head. The first invocation passed 8 files. The other 5 files
failed to import `@paperclipai/plugin-sdk`, because its `dist` was not
built in this fresh checkout. That run reported 37 failed tests, all
from the import error, not from this change. After `pnpm --filter
@paperclipai/plugin-sdk... build`, the same 5 files passed 206 of 206
tests.
- Production evidence (read-only SQL on the affected instance): exactly
two readers in the company fail the current check. Both are on the
blocked root. For both, `heartbeat_runs.issue_id` equals the reader's
task and the context task is a different task after a coalesced
`issue_execution_same_name` wake. Both pass the new rule, so the blocked
root recovers after deployment without data repair.
- Not run: full `pnpm -r typecheck`, `pnpm test:run` and `pnpm build`.
The sandbox has 4 GB of memory. CI runs these checks.

## Risks

- The rule now also accepts a reader whose task equals the run's
immutable binding while the context points to another task. The binding
is the run's privacy binding. The database sets it at insert and does
not let it change, and it requires `native_issue_id` to agree with it.
The reader's own recorded task is still the authorization context.
- The rule keeps the previous context identity. A run that coalesced a
wake before it started and then coalesced another one later could still
produce an unavailable reader. I did not find that sequence in the
affected data. The cross-task coalesce targets a run that already holds
the other task's execution lock, and that happens after admission.
- No schema, migration or API change.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`) through Claude Code in a Paperclip
agent run, with tool use, code execution and read-only SQL diagnostics.
The context window and reasoning settings are managed by the runtime.

## 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

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-19 22:40:25 -05:00
DottaandPaperclip 1f27427ffd perf(server): batch retained workspace reader identities and policies (#16683)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Task startup checks who can read each physical workspace.
> - A shared root retains the identities of earlier runs.
> - The service reloads the same agents, tasks, projects and run
policies for each reader.
> - Database round trips grow with the retained run history and hold the
company provenance lock.
> - This pull request batches these reads within each guarded operation.
Each run keeps its own identity and policy.
> - The benefit is less task preparation time while current access
checks remain in place.

## Linked Issues or Issue Description

Refs #16424.

**What existing behavior does this improve?**

Workspace admission, repository publication and batched read
authorization.

**Current behavior**

A synthetic shared workspace with 64 retained readers makes 680 SQL
calls during a publication check. The same principals are loaded
repeatedly.

**Proposed behavior**

Load retained identities and saved policies in batches of at most 500
IDs. Load project settings once per guarded operation. Reload records
and permission grants on the next operation.

**Reason and benefit**

The local service benchmark with an injected 4 ms loopback round trip
changed from about 7.0 seconds to 0.5 seconds and from 680 SQL calls to
47. This measures synthetic PostgreSQL data, not hosted response
latency.

## What Changed

- Extract retained-reader identity loading and acquisition trust checks
into a focused service module. Select only the identity and trust fields
used by these checks.
- Batch company-scoped run, agent and task lookups. Keep each run's task
binding, responsible user and policy checks.
- Batch saved run-policy reads in read authorization. Keep company and
agent identity checks and ordinary lookup behavior for noncanonical IDs.
- Reuse project settings within one root authorization operation.
- Add query budgets, identity failures, batch-boundary coverage, policy
comparisons and grant-revocation tests.
- Document snapshot lifetime and query scope.

## Verification

- PASS: 197 focused workspace and authorization tests.
- PASS: `pnpm -r typecheck`.
- PASS: `pnpm build`.
- PASS: all current-head hosted CI test groups, Runner checks, E2E
shards, security checks and builds (55 successful checks; two unrelated
Storybook jobs skipped). The local monolithic `pnpm test:run` was
stopped after all equivalent hosted CI groups passed. It has no complete
local result; the hosted matrix supplies the full-suite proof.
- Synthetic real-PostgreSQL benchmark: 383 workspaces and 64 retained
readers; 4 ms simulated loopback round trip. Publication check: 680 ->
47 SQL calls; 7.0-7.1 s -> 0.48-0.51 s. Three concurrent checks:
20.0-23.1 s -> 1.52-2.12 s. Setup and provider execution are excluded.
Live reply timing remains unverified.
- Regression coverage compares complete batched and ordinary
authorization decisions. It checks distinct saved policies for the same
principals, missing identities, company mismatch, task mismatch,
responsible-user mismatch, revoked project grants and changes after the
first operation.
- No new schema, API or UI contract.

## Risks

- A batch must not combine different runs' identities or policies. Each
lookup and policy decision retains its run, company and agent checks.
- Snapshots last for one guarded operation. Later admissions and
publications reload data. No authorization cache survives the operation.
- Restricted project trust checks keep their existing per-run validation
path. Hosted latency remains an acceptance gate.

## Model Used

OpenAI `gpt-6.1-sol` through Codex, with xhigh reasoning, code execution
and tool use. The runtime does not expose the configured 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 21:52:08 -05:00
DottaandPaperclip 69eb3b6eff perf: reduce repository admission filesystem and write overhead (#16425)
Reduce repository preparation latency by resolving each distinct workspace path once per scan, loading overlapping root provenance, and batching source retention writes. Preserve company authorization, fresh alias checks, and preparation timing.

Add a reproducible benchmark and regressions for source identity retention, symlink retargeting, and bounded filesystem and database work.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-15 09:01:04 -05:00
DottaandPaperclip ea4aa185b0 perf: batch retained-reader authorization reads (#16424)
Batch retained-reader project checks through the existing multi-actor read API. Share raw database reads within one call, retain actor-specific privacy and supplied membership data, and avoid loading large saved-run payloads for identity checks.

Keep current-reader writes, distinct saved-run policies, company root fences and later-call revocation checks. Add query-count and access-control regressions. All 255 affected cases and full repository typecheck/build pass. Hosted response-time acceptance remains separate.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-15 07:33:03 -05:00