db: drop duplicate access_tokens hash index - #3408
Conversation
PR SummaryLow Risk Overview Reviewed by Cursor Bugbot for commit 93e7824. Bugbot is set up for automated code reviews on this repo. Configure here. |
❌ 5 Tests Failed:
View the top 3 failed test(s) by shortest run time
View the full list of 1 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
There was a problem hiding this comment.
LGTM — this correctly identifies and drops the redundant standalone index, keeping the UNIQUE constraint's own index intact.
Extended reasoning...
Overview
Single new migration file that drops idx_access_tokens_access_token_hash, a standalone unique index on access_tokens.access_token_hash. I verified in the migration history that this index is genuinely redundant: 20250211160814_add_token_hashes.sql added the column as TEXT UNIQUE, which creates an implicit unique index (access_tokens_access_token_hash_key), and a later migration (20250825102440_add_hash_indexes.sql) added the standalone idx_access_tokens_access_token_hash unique index on the same column — an unintentional duplicate. This PR removes the later, non-constraint-backed duplicate, which is the correct one to drop (the constraint-backed index cannot be removed via DROP INDEX at all, so a mixed-up target would simply fail rather than silently corrupt anything).
Security risks
None. This is a pure schema/index change with no application logic, query, or auth-path modifications. Uniqueness enforcement and hash lookups continue via the constraint's index.
Level of scrutiny
Low. This is a mechanical, well-reasoned online index drop (DROP INDEX CONCURRENTLY, no transaction wrapper, bounded statement_timeout) with a symmetric and correct down migration (clears any leftover INVALID index before recreating). The change is self-contained to one file and matches established patterns in this repo's migration history.
Other factors
Codecov reports full coverage on the change; Cursor Bugbot's own summary corroborates the redundant-index analysis. No outstanding review comments to address.
access_tokens.access_token_hash carries two identical unique indexes: the UNIQUE constraint's own and a standalone copy. Identical indexes are interchangeable to the planner, so lookups continue on the constraint's index and uniqueness is untouched; every token write stops maintaining the second copy. The standalone twin is the droppable one — the constraint-backed index refuses DROP INDEX, making a mixed-up drop fail loud instead of silently.
Schema proof, both definitions in this repo: the standalone unique index (20250825102440 L9-L10) and the column's UNIQUE constraint that already carries its own index (20250211160814 L12) — identical key
(access_token_hash). Background: PostgreSQL wiki — duplicate indexes.