fix(search): tag autocomplete caches with LISTINGS_TAG#34
Merged
Conversation
getLocationSuggestions and getPopularLocations were cached for 1h without any tags. That meant any stale entry — including the empty-array result returned by the catch block when pg_trgm wasn't yet installed — survived for the full TTL even after a fix was deployed. Concrete production receipt: 1. PR #26 deployed trigram code that needs pg_trgm 2. Migration didn't apply (P3005), operator threw, catch returned [] 3. unstable_cache stored {q:'khartom', limit:10}: [] 4. Migration was applied manually 30 min later 5. Direct DB: 'khartom' % 'Khartoum' returns true ✓ 6. But /api/search/locations?q=khartom still returned [] for ~1h because the cache key was bound to the broken result Fixing forward: tag both autocomplete caches with LISTINGS_TAG — the same tag listing mutations already call updateTag() against. Now create/update/publish/unpublish/delete invalidate autocomplete in addition to /listings, and a deploy that fixes a query path takes effect within the next mutation rather than waiting an hour. Verified locally: pnpm typecheck → exit 0 pnpm vitest run tests/actions/search-actions.test.ts → 19/19 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
getLocationSuggestionsandgetPopularLocationswereunstable_cache-wrapped with a 1h TTL but no tags. That meant the only way an entry got refreshed was the TTL —revalidateTag()andupdateTag()were no-ops against them.Today's deploy hit this concretely:
pg_trgmmigration ran.[]for every fuzzy query for ~30 minutes.(query, limit)keys.[]for the original cached queries until the TTL elapsed — everyq=khartomrequest kept serving the broken result.I confirmed the diagnosis live:
q=Khartom(capital K, never cached) returned the correct 3-city match, whileq=khartom(lowercased, originally cached empty) still returned[].Fix
Both autocomplete
unstable_cachecalls now declaretags: [LISTINGS_TAG]. The mutations inlisting-actions.ts(create/update/publish/unpublish/delete) already callupdateTag("listings")to invalidate the listings page cache — those same calls now also bust autocomplete. A deploy that fixes a query path takes effect within the next mutation rather than waiting an hour.Validation
pnpm typecheckpnpm vitest run tests/actions/search-actions.test.ts🤖 Generated with Claude Code