## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Managed Git workspaces retain task and run obligations until cleanup is safe. > - Activity, expiration, retention and rehome share a run association query. > - That query repeatedly extracted three keys from wide historical JSON contexts. > - This pull request decodes those keys together and projects the six fields its consumers use. > - Native bindings, cleanup vetoes, lifecycle locks and fresh deletion checks stay in place. > - The benefit is less database work while preserving the same cleanup decisions. ## Linked Issues or Issue Description **What happened?** Workspace activity and eligibility queries repeatedly decompress large run contexts. An OR predicate extracts issue, task and workspace compatibility keys separately. The run scope also materializes columns its lifecycle consumers do not read. **Expected behavior** Read the same relevant runs and preserve all deletion and rehome vetoes with less repeated JSON work. Keep existing native, historical and pointer bindings independent. **Steps to reproduce** Run the synthetic PostgreSQL comparison below against baseline `db70c5acd92f50fa37fb4f0dea3da0e7685089a2`. Repeat the small, large-tree and combined controls documented in the PR. Related work: #17464 preserves workspace descendants. #17877 reconstructs native workspace obligations. This change preserves both contracts and adds no scheduling change. ## What Changed - Decode the three legacy context keys together with `jsonb_to_record`. A strict root-object guard preserves scalar, array and null behavior. Independent native and pointer bindings still match. - Materialize the full textual tree-ID set once. This avoids inflated recursive estimates triggering JIT compilation for the correlated decoder. - Project the six run lifecycle columns used by activity, expiration, orphan retention and rehome. - Add binding, lease, malformed-shape and fresh-read regression cases. Add a reproducible four-control benchmark and detailed evidence documentation. ## Verification - Full repository typecheck passed on the integrated final source. - Six relevant suites passed all 209 tests against real PostgreSQL, including the 20 new binding/shape cases, 25 eligibility cases, full Git expiration/restoration, task-directory retention and configuration, and isolated repository rehome. These cover conflicting bindings, company isolation, duplicate admission, pending cleanup, controller leases, non-object contexts and newly active consumers. - PostgreSQL 17.11 comparisons use two warmups and five alternating samples per variant. Each sample runs eight sequential workspace queries. Every complete caller result and six-column relevant-run multiset matches. - Stress fixture: 4,813 runs and about 332 MB of run storage, with unique wide contexts. Last-activity median: 1,071.54 to 743.45 ms per eight workspaces, 1.44 times faster. Closed eligibility: 814.29 to 713.86 ms, 1.14 times faster. Idle eligibility: 721.46 to 481.69 ms, 1.50 times faster. - Small-history control improves 1.23–1.36 times. The 250-descendant stress control improves 1.24–1.30 times. Combined small-history/large-tree activity and idle checks improve 1.19–1.22 times. Combined closed eligibility is neutral: 61.11 to 62.82 ms per eight, about 0.21 ms extra per workspace. - Stress last-activity ranges do not overlap: 920.27–1,111.22 ms before and 689.14–880.40 ms after. Closed-eligibility ranges overlap; its smaller median gain is directional. - Last-activity buffer accesses fall from 113,202 to 38,081. Eligibility run width falls from about 1,414 to 57 planner bytes. All final plans retain one history scan with no JIT. - Reproduce: `pnpm --filter @paperclipai/server exec tsx ../scripts/benchmark-workspace-activity.ts --baseline-ref=db70c5acd92f50fa37fb4f0dea3da0e7685089a2 --docker-postgres=17 --reject-new-jit --output-dir=/tmp/workspace-activity-stress`. - Repeat with `--small`, `--descendants=250`, and both flags, using distinct output directories. Each run creates and removes its own synthetic database. - Full CI passed on `bc4edd700f983e22f093d0a01e2f4c795075b982`: 54 successful checks, one neutral review and two expected Storybook skips, plus successful Snyk status. Greptile is 5/5 on this exact head. There are zero unresolved threads and the merge state is clean. [CI run](https://github.com/paperclipai/paperclip/actions/runs/40530494291). - Full repository typecheck and build passed on the integrated final source. The local full test command was stopped after native PostgreSQL initialization failed repeatedly, producing 16 failures and skipped database suites. It is incomplete, not a pass. Focused real-database suites used disposable Docker PostgreSQL. Current-head CI passed all full gates separately. ## Risks - Cleanup safety depends on complete run association. Tests compare every retained run field and exercise downstream vetoes, not only row counts. - PostgreSQL plan estimates matter. Rejected per-key index probes were up to 56 times slower on a small-history/large-tree control. An ANY variant also regressed. The final shape passes all four controls under default JIT settings. - The final combined eligibility control is neutral. Synthetic SQL timings do not establish deployed latency, provider behavior or actual compute sleep. - Review suggested a CASE/jsonb_typeof root guard as an optional alternative. The strict JSONPath guard is retained because its scalar, nested-array and independent-native behavior passes real PostgreSQL tests and all four measured controls. No correctness defect was identified. A replacement needs its own comparative measurements. - Future consumers that need another run column must extend this explicit projection. - No migration, index, startup job, polling change or deployment is included. ## Model Used OpenAI Codex, configured model `gpt-6.1-sol` with xhigh reasoning, tool use and code execution. Independent blast-radius review also used `gpt-6-astra` and `gpt-6.1-sol`. The runtime context window was 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>
9.2 KiB
Workspace activity query performance
The workspace activity query reads three compatibility keys from each retained run context. Wide contexts made those separate JSON extractions expensive. The same scope also materialized complete run rows for cleanup checks that consume only six lifecycle fields.
The implementation extracts issueId, taskId, and executionWorkspaceId
together through jsonb_to_record, after native task bindings and bound
checkout/execution-run pointers have had a chance to match. Strict JSONPath
passes only a top-level object to the record function. Arrays, scalars and JSON
null therefore retain their former unmatched legacy-key behavior; their native
bindings remain independent. PostgreSQL documents the
strict path and type semantics.
The full tree's textual IDs are materialized once for the decoder's membership checks. This also prevents recursive cardinality estimates from inflating the correlated decoder's startup cost enough to trigger expensive JIT compilation. The key set has no result limit. Empty trees produce an empty set.
Contract and blast radius
The safety fact is that the same runs supply the same lifecycle fields. Native and legacy bindings remain independent, including conflicting bindings. The run scope retains descendants, tasks bound outside the tree, explicit bound checkout/execution pointers, exact textual UUID comparisons, company scope, duplicates and null behavior.
| Consumer | Fields read from the run scope | Consequence of a missing run |
|---|---|---|
gitWorkspaceLastActivityAt |
Created, started and finished timestamps | Expiration may be scheduled too early. |
isGitWorkspaceExpirationEligible |
ID, status, all three timestamps, controller lease expiry | A live run or its persistence/cleanup obligation could stop vetoing deletion. |
Task-directory orphanConsumer |
ID, status, finish time, controller lease expiry | An orphan folder could be removed while a run, finalization or lease still needs it. |
workspaceMoveEligible |
ID, status, finish time, controller lease expiry | Re-home could move a workspace used by a live controller. |
All six fields remain projected. The task, recovery, finalization, environment
lease and runtime-service checks keep their existing mode-specific rules.
Deletion still rechecks current eligibility after the beforeDelete boundary,
under the existing source/lifecycle locks. Shared-path rejection still precedes
run-history evaluation.
The deterministic database tests exercise nine independent binding paths, downstream pending-cleanup leases referenced only through a run ID, conflicting native/legacy bindings, multiply bound runs, case-sensitive legacy IDs, cross-company decoys, current controller leases, new consumers between reads, and null/scalar/array/nested-array contexts with and without native bindings. Fixture insertion disables the scope-normalization trigger in disposable databases so legacy-path tests cannot silently become native-binding tests.
The benchmark compares complete positional caller results and the complete multiset of all six relevant-run fields. This is evidence level 4 from the blast-radius workflow: real code and real PostgreSQL. Deployed behavior and production latency still require a rollout and fresh measurements.
Reproduce the measurements
The baseline is db70c5acd92f50fa37fb4f0dea3da0e7685089a2. The harness loads
that service source with its unchanged current imports and captures the actual
SQL generated by the baseline and checked-out service. Reports save source
snapshots, SHA-256 digests, the source diff, all samples, complete SQL/parameters,
database settings, and EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) plans.
The Docker option creates and removes its own disposable PostgreSQL 17
container, applies normal migrations, and uses synthetic data. It does not use
DATABASE_URL. Without that option the harness uses the normal embedded
PostgreSQL test helper.
pnpm --filter @paperclipai/server exec tsx ../scripts/benchmark-workspace-activity.ts \
--baseline-ref=db70c5acd92f50fa37fb4f0dea3da0e7685089a2 \
--docker-postgres=17 --reject-new-jit --output-dir=/tmp/workspace-activity-stress
Run the other controls with --small, --descendants=250, and
--small --descendants=250, using separate output directories. Defaults are two
warmups and five measured samples per version, with baseline/treatment order
alternating. --samples=1 --warmups=0 is diagnostic only. --reject-new-jit
saves non-executing preflight plans and stops before repeating a newly expensive
JIT plan.
Each timing sample includes eight sequential workspace queries. The stress fixture has 4,813 runs; the small control has 141. Every wide run has roughly 32 KiB of incompressible context padding and 32 KiB of result padding, with a unique context nonce. The large-tree controls have 250 descendants per workspace. Statistics are refreshed before timing.
The accepted source SHA-256 is
cd784320265af7857b534d705dbdbe09e732014f2be160971dd89e6d6219029a.
All four reports have that digest. These measurements used PostgreSQL 17.11 on
Linux/aarch64 in Docker, with work_mem=4MB. The run relation including indexes
and TOAST was about 331.8 MB for stress and 9.15 MB for the small controls.
| Fixture | Query | Before median, ms/8 | After median, ms/8 | Before / after |
|---|---|---|---|---|
| Stress, 1 descendant | Last activity | 1,071.54 | 743.45 | 1.44x |
| Stress, 1 descendant | Closed eligibility | 814.29 | 713.86 | 1.14x |
| Stress, 1 descendant | Idle eligibility | 721.46 | 481.69 | 1.50x |
| Small, 1 descendant | Last activity | 20.53 | 15.06 | 1.36x |
| Small, 1 descendant | Closed eligibility | 21.85 | 16.64 | 1.31x |
| Small, 1 descendant | Idle eligibility | 21.91 | 17.74 | 1.23x |
| Stress, 250 descendants | Last activity | 740.35 | 582.55 | 1.27x |
| Stress, 250 descendants | Closed eligibility | 678.95 | 549.16 | 1.24x |
| Stress, 250 descendants | Idle eligibility | 948.03 | 728.78 | 1.30x |
| Small, 250 descendants | Last activity | 45.51 | 38.09 | 1.19x |
| Small, 250 descendants | Closed eligibility | 61.11 | 62.82 | 0.97x, neutral |
| Small, 250 descendants | Idle eligibility | 46.28 | 38.02 | 1.22x |
The stress last-activity samples did not overlap: baseline 920.27–1,111.22 ms and treatment 689.14–880.40 ms per eight workspaces. Closed-eligibility timings were noisier; its stress range was 649.58–2,138.92 ms versus 546.43–842.67 ms. Treat that smaller median gain as directional. The combined closed-eligibility control also had overlapping ranges, 59.01–82.96 versus 48.41–121.52 ms; its 1.72 ms median difference per eight workspaces is neutral evidence.
The plans support the mechanism independently of timing noise. Stress last-activity buffer accesses fell from 113,202 to 38,081. The decoder ran 4,752 times for 4,812 company rows, retaining native short-circuit behavior. Materialized eligibility run width fell from about 1,414 to 57 planner bytes. All final plans retained one history scan without JIT. Every measured caller result and complete relevant-run multiset matched the baseline.
Rejected query shapes
These failures informed the final shape and are not accepted performance results:
| Candidate | Decisive result |
|---|---|
| Split binding joins without parameterization | Legacy hash joins caused additional wide-context scans; roughly twice the baseline SQL time. |
| Per-tree-node indexed probes | A 250-descendant fixture activated JIT and became roughly 5–8 times slower. |
| Aggregate-key-set per-node probes | Removed JIT, but small history plus 250 descendants chose one sequential scan per node and became 43–56 times slower. |
Separate ANY(ARRAY(...)) binding queries |
Cleared the small/large-tree regression but performed separate history scans on the stress fixture and became roughly 1.7–1.8 times slower. |
| Correlated record decoder reading the recursive tree directly | A non-executing preflight found new JIT with estimated cost 156,621; rejected before repeated timing. |
The final query retains one history scan and shares the materialized membership key set. It changes neither scheduling frequency nor retention policy. Batching the advisory last-activity reads is deferred so this change keeps the existing reaper lifecycle and destructive freshness checks intact.
Before merging or rolling out
Run the binding/eligibility tests and the existing Git expiration, directory retention and repository re-home suites. They cover actual filesystem removal, restoration, unique work, unresolved consumers, reopening and concurrent changes.
pnpm --filter @paperclipai/server exec vitest run \
src/__tests__/git-workspace-activity.test.ts \
src/__tests__/git-workspace-expiration-eligibility.test.ts \
src/__tests__/git-workspace-expiration.test.ts \
src/__tests__/isolated-task-directory-retention.test.ts \
src/__tests__/isolated-repository-rehome.test.ts
Also complete the repository's required typecheck, full tests and build on the final source. After an authorized rollout, confirm the deployed revision and compare fresh query-statistics deltas and cleanup behavior. Local synthetic SQL measurements do not establish a production latency improvement.