mirror of
https://github.com/pezkuwichain/pwap.git
synced 2026-08-12 20:51:37 +00:00
pezkuwichain
658c99b9bb
A user hit "Could not find the function public.upsert_user_profile(...) in the schema cache" when toggling push notifications. The function was missing, and so were the profiles columns it writes — while schema_migrations listed both 002 and 004 as applied. That pattern turned out to be widespread. Comparing every function declared across the migrations against the live database: 25 are missing, from six migrations all recorded as applied. Their tables exist; only the function bodies are absent. Those files carry "Run this in Supabase SQL Editor" headers, so they were pasted in by hand before apply-migrations.sh existed and a run that stopped partway was still recorded. The runner has skipped them ever since, which is why this stayed invisible until it surfaced as a user-facing error. apply-migrations.sh is not at fault: it wraps each migration and its tracking row in one transaction with ON_ERROR_STOP, so it cannot half-record anything. It inherited a dirty history. Three of the 25 are actually reached by the app, so those are repaired here: apply_for_tier_upgrade MerchantApplication.tsx:213 - tier upgrades were dead check_tier_eligibility called by the above update_p2p_reputation shared/lib/p2p-fiat.ts:803 - reputation never updated This is forward-only repair, not a replay of the source files. Replaying them would abort on their bare CREATE POLICY/INDEX/TRIGGER statements now that the tables exist, and 20241117054602 in particular would overwrite 016's newer cancel_expired_trades with its own older definition. Verified before writing: every table the three functions touch is present, and the whole migration was run inside BEGIN/ROLLBACK against production — three functions created, signatures matching what the callers pass, then rolled back leaving nothing behind. The remaining 22 stay missing on purpose and are listed in known-schema-gaps.txt. Nothing calls them, and several are trigger bodies whose triggers were never created either, so creating them would switch on behaviour that has never run. Also adds a drift check to apply-migrations.sh: after applying, it compares declared functions against the database and flags anything missing that is not in the known-gaps list. Being recorded as applied is not proof of having been applied, and that gap should never again be discovered by a user. The check already earned itself — it caught update_p2p_reputation, which my own first pass had missed to a regex that dropped digits from function names. upsert_user_profile and the profiles notification columns were applied directly to the database from their existing migrations (002, 004), which are fully idempotent; no new migration was needed for them.