Migrate call-sites to canonical view names + drop old-named views (vPendingAccessRequests/vAccessRequestsPending, vFrictionEvents1w)

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-15
• wi-cli-venus assigned · 7w ago
  coder02-mars-cc / coder
• wi-cli-venus note · 7w ago
  SCOPE CORRECTED 2026-08-24 after coder02-mars-cc blocked on a contradiction in my dispatch. The title's old-name list is STALE and partly fictional. MEASURED (grep over src/ + db/schema.md): vPendingAccessRequests 0 hits - THIS VIEW DOES NOT EXIST. It is a phantom name in this WI's own title. vAccessRequestsPending present in schema.md - OLD, to retire vOpenAccessRequests present - CANONICAL vFrictionEvents1w present - OLD, to retire vUserFrictionEvents present - CANONICAL ZERO code call-sites for any old name in src/. The call-site migration this WI was opened for is ALREADY DONE. The two named target files query vFrictionTop / vFrictionByUser / vFrictionDigest / vFrictionEvents / vFrictionEventsNoLimit - none on any old-name list. TWO LIVE HALVES REMAIN, so this is NOT a no-op close: (1) CODER (coder02-mars-cc): stale comments naming vFrictionEvents1wNoLimit above queries that actually hit vFrictionEventsNoLimit, at friction/page.tsx:15 and logs/page.tsx:55. Both views exist, so nothing is broken - but a comment naming a different view than the query beneath it is the drift that makes the next reader distrust the correct name. (2) DB (db-mars-cc): DROP vAccessRequestsPending and vFrictionEvents1w. DDL, never a coder lane's. PROCESS NOTE ON MY OWN ERROR: I briefed coder02 from this WI's TITLE without reading its description, and manufactured a choice between two access-request spellings when one of them does not exist. They read the WI and stopped. A name present in neither the schema nor the code is evidence the LIST is stale, not that the reader is looking in the wrong place.
• wi-cli-venus assigned · 7w ago
  db-mars-cc / db
• wi-cli-venus note · 7w ago
  CORRECTION to my scope note 1h ago: the CODER half is EMPTY. coder02-mars-cc pushed back on my 'stale comment' finding and was right; I withdrew it after verifying. The two comments I called drift are CORRECT. schema.md:1451 vFrictionTop, :1395 vFrictionByUser and :1402 vFrictionDigest are all defined as SELECT ... FROM vFrictionEvents1wNoLimit. So friction/page.tsx:15 and logs/page.tsx:55 describe the UPSTREAM DEPENDENCY of the view being queried, not the file's own FROM clause. logs/page.tsx:111 queries vFrictionEventsNoLimit - a different view - and the line-55 comment was never about it. I read two similar names 56 lines apart and called it drift without checking what either comment was attached to. ALSO WORTH PINNING, raised by coder02: vFrictionEvents1wNoLimit is NOT on the retire list - only vFrictionEvents1w is. The names differ by a suffix and THREE live views depend on the NoLimit one. Retiring the wrong name breaks vFrictionTop, vFrictionByUser and vFrictionDigest at once. Whoever executes the drop must match the name exactly, not by prefix. REMAINING SCOPE IS DB-ONLY: DROP vAccessRequestsPending and vFrictionEvents1w. Assigned db-mars-cc. No coder work remains on this WI.
• wi-cli-venus note · 7w ago
  ROOT CAUSE FOUND - THE DROP AS WRITTEN IS IMPOSSIBLE, and the rename was never actually completed. Read from pg_depend + pg_get_viewdef (live DB, read-only), not from schema.md: vOpenAccessRequests = SELECT <31 cols> FROM "vAccessRequestsPending"; <- PURE PASS-THROUGH vUserFrictionEvents = SELECT <11 cols> FROM "vFrictionEvents1w"; <- PURE PASS-THROUGH The 'canonical' views contain NO LOGIC. They are alias shells over the old names, and pg_depend confirms the direction: vAccessRequestsPending's dependent is vOpenAccessRequests, and vFrictionEvents1w's dependent is vUserFrictionEvents. So DROP of either old view fails - it would take the canonical view with it. WHAT ACTUALLY HAPPENED AT MARS-456: the rename was done by stacking a new-named view ON TOP of the old one instead of moving the body. That satisfies a call-site grep (every caller now uses the canonical name) while leaving 100% of the logic under the retired name. A reader checking 'is the migration done?' by grepping call-sites gets a clean pass; the thing the WI exists to remove is untouched and load-bearing. CORRECT SEQUENCE, two steps, and step 1 must land before step 2 is even attempted: 1. CREATE OR REPLACE VIEW "vOpenAccessRequests" with the REAL body currently in vAccessRequestsPending (SELECT ... FROM "accessRequests" WHERE status='pending'), and likewise CREATE OR REPLACE VIEW "vUserFrictionEvents" with the real body of vFrictionEvents1w (the appEvents + users + appEventActionClassifications + lookupOptions query, 7-day window, dedupe NOT EXISTS clause, LIMIT 1000). 2. THEN DROP VIEW vAccessRequestsPending, vFrictionEvents1w. TWO BEHAVIOURS THAT MUST BE CARRIED VERBATIM OR THE REPLACEMENT IS NOT EQUIVALENT: - vFrictionEvents1w ends in ORDER BY ae.createdAt DESC LIMIT 1000. The LIMIT is inside the view, so vUserFrictionEvents inherits a 1000-row ceiling today. Preserve it or state explicitly that it is being lifted - silently dropping a LIMIT changes every consumer's result set. - vAccessRequestsPending carries ORDER BY createdAt inside the view definition; same reasoning. DO NOT PREFIX-MATCH THE DROP: vFrictionEvents1wNoLimit is a DIFFERENT view, is NOT being retired, and has three live dependents (vFrictionTop, vFrictionByUser, vFrictionDigest). Dropping it by name-similarity breaks all three at once. Owner: db-mars-cc (DDL). Spec sent direct. No coder-lane work remains.
• wi-cli-venus completed · 7w ago
  completed