chore(file-search): retire legacy index storage

[icecrasher321]

Summary

• Retire the legacy file-search index and segment tables after the chunk-storage rollout in improvement(file-search): publish complete indexes in bounded text chunks #7947. Drop them atomically with a two-second lock timeout, without CASCADE or row-by-row deletion; leave current chunks, revision metadata, the status enum, and the dispatch/backfill state intact.
• Remove obsolete schema declarations, mocks, and the timestamp repair's legacy deletion branch. Preserve revision normalization and secret provenance.
• Draft: merge only after fix(file-search): bound chunk inserts by trigram work #8011 is deployed and verified, the chunk backfill is complete, old worker runs have drained, and the rollback window is closed. After retirement, application rollback must remain chunk-compatible.

Type of Change

• Maintenance

Testing

• 172 file-search unit tests and 11 PostgreSQL revision/provenance tests.
• PostgreSQL 16 and 17: 56 integration tests passed on each, with one optional benchmark skipped. Checks include atomic rollback on an unexpected dependency, safe migration replay, exact/regex results and line numbers, publication, deletion, and cleanup after legacy retirement.
• Real migration runner on a fresh disposable PostgreSQL 17 database and a no-op replay; Drizzle schema parity, migration safety, app/database type checks, full lint, all 47 audits, and docs/block checks.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Sep 19, 2026 6:00pm UTC

[greptile-apps]

Confidence Score: 4/5

The PR is not safe to merge until the retirement migration guarantees an active transaction on fresh and lagging database installations.

Findings

1.  Retirement Is Not Atomic ▶

Summary

This PR retires the legacy segment-based file-search storage after the chunk-storage rollout.

• Drops the legacy index and segment tables while retaining chunk, revision, dispatch, backfill, and status-enum state.
• Removes obsolete Drizzle declarations, test mocks, and timestamp-repair cleanup logic.
• Adds retirement and replay coverage, but the migration is not atomic on fresh or sufficiently lagging installations because earlier migrations terminate the runner transaction.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Drizzle starts migration transaction] --> B[Earlier pending migration executes COMMIT]
  B --> C[0368 SET LOCAL runs in autocommit and is ignored]
  C --> D[Drop legacy segment table commits]
  D --> E{Drop legacy index table succeeds?}
  E -->|Yes| F[Both legacy tables retired]
  E -->|No| G[Partial retirement: segment dropped, index retained]

Loading

_{Reviews (1) · Last reviewed commit: "chore(file-search): retire legacy index ..."}

[greptile-apps]

Retirement Is Not Atomic

On fresh installs or deployments migrating from before 0365, earlier pending migrations execute COMMIT, ending Drizzle’s transaction without starting another. This makes SET LOCAL ineffective and causes the two table drops to commit separately. If the second drop fails because of a dependency or lock conflict, the segment table remains permanently dropped instead of both changes rolling back atomically. Ensure this retirement runs inside an explicit transaction.

[cubic-dev-ai]

1 issue found across 9 files

Confidence score: 4/5

• packages/db/migrations/0368_retire_legacy_file_search.sql applies SET LOCAL after COMMIT, so the setting is ignored by the real migration runner and the drops retain the 5-second timeout instead of 2 seconds; use a session-level SET or wrap the statements in a transaction.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/db/migrations/0368_retire_legacy_file_search.sql">

<violation number="1" location="packages/db/migrations/0368_retire_legacy_file_search.sql:1">
P2: When the real runner applies this post-`COMMIT` migration, `SET LOCAL` runs outside a transaction and is ignored, so the drops use the runner's 5-second timeout instead of 2 seconds. Use a session-level `SET` or wrap the drops in an explicit transaction.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: When the real runner applies this post-COMMIT migration, SET LOCAL runs outside a transaction and is ignored, so the drops use the runner's 5-second timeout instead of 2 seconds. Use a session-level SET or wrap the drops in an explicit transaction.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/db/migrations/0368_retire_legacy_file_search.sql, line 1:

<comment>When the real runner applies this post-`COMMIT` migration, `SET LOCAL` runs outside a transaction and is ignored, so the drops use the runner's 5-second timeout instead of 2 seconds. Use a session-level `SET` or wrap the drops in an explicit transaction.</comment>

<file context>
@@ -0,0 +1,7 @@
+SET LOCAL lock_timeout = '2s';
+--> statement-breakpoint
+-- migration-safe: contract of #7947; deployed app, workers, and revision triggers use chunk storage. Retire only after the rollback window and completed backfill verification.
</file context>

Suggested change

	SET LOCAL lock_timeout = '2s';
	SET lock_timeout = '2s';