You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. Deploy the additive migration and new application/Trigger worker versions. Legacy index tables remain readable for the old deployment. The file trigger queues current revisions in the new table; this cutover intentionally allows temporary search unavailability while the new index builds.
44
44
2. The dispatcher uses a separate `workspace-file-search-chunks-v2` backfill cursor. It seeds at most 1,000 active files per pass under a shared file lock, with idempotent inserts. Normal dispatch caps remain two outstanding jobs per workspace, 100 outstanding globally, and ten running workers. Reconciliation repeats hourly after a complete pass to repair missing metadata. Failed revisions remain visible as failed; they are not silently declared covered.
45
45
3. Before retiring legacy storage, verify the new app and Trigger workers are fully deployed, old runs/retries have drained, the backfill cursor has completed, and scoped coverage is ready or explicitly excluded. Investigate failed or stale pending revisions. Check cleanup backlog and run representative exact/regex searches, including long lines and folder scopes.
46
-
4. After the rollback window, ship a separate contract PR removing the legacy schema and dropping `workspace_file_search_segment`/`workspace_file_search_index`with a short lock timeout. Do not delete the entire old index row-by-row or backfill it inside the schema migration. Dropping obsolete tables reclaims their heap, indexes, and TOAST together. The `contract-pending` marker in `packages/db/schema.ts` tracks this step.
46
+
4. After the rollback window and the checks above, deploy `0368_retire_legacy_file_search.sql`. It drops only `workspace_file_search_segment`and`workspace_file_search_index`, atomically, with a two-second lock timeout and without `CASCADE`. An unexpected dependency or lock conflict aborts the migration instead of removing dependent objects. Replay tolerates tables already retired. Dropping the tables reclaims their heap, indexes, and TOAST together; it does not delete current chunks or rebuild search.
47
47
48
-
Until that contract deploy, legacy foreign-key cascades can still make a hard file/workspace deletion expensive. New-index cleanup is bounded; retaining the old schema cannot erase that legacy cost. The earlier timestamp-repair script detects the chunk schema and leaves obsolete legacy text for this contract step instead of deleting it in bulk. Legacy-table retirement remains a separate contract migration.
48
+
The status enum, dispatch queue, and v2 backfill cursor remain in use. The timestamp-repair script still preserves provenance and repairs current revisions; its legacy deletion branch has been removed. No bulk deletion or replacement backfill runs in the contract migration.
49
49
50
-
Rollback before retirement requires restoring the old trigger function as well as the old app/worker version, and reconciling legacy revisions written during the cutover. Do not assume retained tables are automatically up to date. Canonical revision joins prevent stale content from being returned.
50
+
After retirement, rollback must stay on a chunk-compatible appand worker release. Restoring the old segment-based implementation requires recreating and rebuilding its retired storage; reverting application code alone is insufficient.
-- migration-safe: contract of #7947; deployed app, workers, and revision triggers use chunk storage. Retire only after the rollback window and completed backfill verification.
4
+
DROPTABLE IF EXISTS "workspace_file_search_segment";
5
+
--> statement-breakpoint
6
+
-- migration-safe: contract of #7947; current revision metadata lives in workspace_file_search_revision, with no remaining runtime reader of this legacy table.
7
+
DROPTABLE IF EXISTS "workspace_file_search_index";
0 commit comments