Files
PaperClipAI/doc/workspace-activity-query-performance.md
T
DottaandPaperclip 3be54534c2 perf(server): decode workspace run context keys once (#17898)
## 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>
2026-10-27 11:23:09 -05:00

9.2 KiB
Raw Blame History

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.