#195: trashed content leaves the search index itself #250

fable-5 · 2026-07-30T14:07:54+02:00

fable-5 commented

2026-07-30 14:07:54 +02:00

Implements #195:

Page trash (promote + subtree) clears the affected search_vector rows; page restore rebuilds them. Pond trash clears every page vector of the pond; pond restore reindexes only LIVE pages (pages trashed inside stay out). The GDPR pseudonymization (personal-pond trash) clears too.
reindexAll (CLI) now converges to the invariant: clears trashed vectors, rebuilds live pages of live ponds. New SearchProvider methods removePond/reindexPond keep the engine seam intact.
One-off backfill migration clears vectors of already-trashed content.
The query-side deleted_at guards STAY as the independent second layer (also load-bearing for the LIKE fallback branch, which matches plain_text regardless of the vector).
security.md records the invariant and the two layers.

Tested: new search-trash.e2e.db.test.ts asserts the INDEX ROWS themselves (vector::text via raw SQL), restore behaviour incl. subtree and pond cases (still-trashed child stays out after pond restore), and the second layer independently by writing a vector back onto a trashed page - the query still hides it. api full suite 462 green vs fresh DB; typecheck + lint green.

Refs #195 (close manually after green CI + merge).

Generated with Claude Code (Claude Fable 5)

Implements #195: - Page trash (promote + subtree) clears the affected search_vector rows; page restore rebuilds them. Pond trash clears every page vector of the pond; pond restore reindexes only LIVE pages (pages trashed inside stay out). The GDPR pseudonymization (personal-pond trash) clears too. - reindexAll (CLI) now converges to the invariant: clears trashed vectors, rebuilds live pages of live ponds. New SearchProvider methods removePond/reindexPond keep the engine seam intact. - One-off backfill migration clears vectors of already-trashed content. - The query-side deleted_at guards STAY as the independent second layer (also load-bearing for the LIKE fallback branch, which matches plain_text regardless of the vector). - security.md records the invariant and the two layers. Tested: new search-trash.e2e.db.test.ts asserts the INDEX ROWS themselves (vector::text via raw SQL), restore behaviour incl. subtree and pond cases (still-trashed child stays out after pond restore), and the second layer independently by writing a vector back onto a trashed page - the query still hides it. api full suite 462 green vs fresh DB; typecheck + lint green. Refs #195 (close manually after green CI + merge). Generated with Claude Code (Claude Fable 5)

fable-5 added 1 commit 2026-07-30 14:07:54 +02:00

#195 : trashed content leaves the search index itself

CI / Lint, typecheck, test (pull_request) Successful in 5m4s

Details

CI / Build container images (pull_request) Successful in 2m47s

Details

CI / Auth e2e pack (pull_request) Successful in 7m44s

Details

CI / Import/export fidelity gate (pull_request) Successful in 55s

Details

CD / Build and push images (push) Successful in 19s

Details

CD / Deploy to Test (push) Successful in 13s

Details

CD / Smoke tests against Test (push) Successful in 1m22s

Details

CD / Promote to Int (push) Successful in 11s

Details

CI / Lint, typecheck, test (push) Successful in 5m9s

Details

CI / Build container images (push) Has been skipped

Details

CI / Auth e2e pack (push) Successful in 7m53s

Details

CI / Import/export fidelity gate (push) Successful in 53s

Details

960a806ee3

Trashing a page (promote and subtree modes) clears the affected search
vectors, restoring rebuilds them; pond trash clears every page vector of
the pond, pond restore reindexes only the live pages (pages trashed
inside stay out); the GDPR pseudonymization's personal-pond trash does
the same. reindexAll now converges to the invariant (clears trashed,
rebuilds live), and a one-off migration backfills vectors of
already-trashed content.

The query-side deleted_at guards stay untouched as the independent
second layer - the test proves both layers separately, including writing
a vector back onto a trashed page (simulating a future path that forgot
the clear) and asserting the query still hides it. New provider methods
removePond/reindexPond behind the SearchProvider seam.

Refs #195

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0168Ph5uBmHm8X28CSVpbpnJ

fable-5 merged commit 960a806ee3 into main

2026-07-30 14:22:50 +02:00

fable-5 referenced this pull request

2026-07-30 14:22:50 +02:00

[VS-NfD] Remove trashed content from the search index instead of filtering at query time #195

Sign in to join this conversation.

No reviewers