Verify restored-Mars object completeness after bin-whey-cc's rail patch
MARS-667 closed on the documentation deliverable; this is the Mars-side verification that remains. bin-whey-cc reproduced the 8 pg_restore errors from drill 5 against the same artifact and six objects are ABSENT from a restored Mars: trigram indexes users_email_trgm / users_emailLocalPart_trgm / users_displayNameUnaccent_trgm (extensions schema out of dump scope), the view vAccessRequestsForReview (same cause - this is the access-request fuzzy duplicate-candidate matcher, a real surface lost not just slowed), vMatviewRefreshRuns24h (cron.job_run_details out of scope) and vMatviewRefreshRollup24h as its cascade, plus auth.mfa_amr_claims_session_id_fkey which cannot be created because excluding auth.sessions ROWS while keeping mfa_amr_claims ROWS leaves orphans - refuting run.sh:67-70's stated reason for preferring --exclude-table-data, wrong since 2026-06-10. KEY POINT: all eight are DDL, zero table data lost, so the 0.43% row delta is unaffected and even a per-table expected==restored assertion would have PASSED this restore. A row count cannot see a missing view, index or FK. The drill needs object counts BY KIND. Fixes are in bin-whey-cc's pending patch (add --schema=extensions, --schema=cron --extension=pg_cron, exclude auth.mfa_amr_claims data alongside auth.sessions, assert object counts by kind), blocked on Elazar's GO. bin-whey-cc will re-run the drill and send the before/after error set. MARS ACTION WHEN THAT LANDS: confirm the before/after set shows zero errors, verify the six objects are present in a restored scratch DB, and update mars/shared/md/mars-backup.md (documented at HEAD as of today). No Mars code change - the remedy is entirely in the rail on whey. Not urgent per Elazar's 2026-08-22 risk ruling (paper backups exist for every practica, images on Hostinger, restore-and-diff is not a crisis).
Activity
-
audit-mars-ca holds the P1 BLOCK on THIS item (transferred from MARS-667, whose docs audit treats as accurate but explicitly NOT evidence of restore readiness). Acceptance criteria stated by audit, verbatim in substance - clear only when ALL hold: (1) bin-whey-cc's rail patch is LIVE, not drafted; (2) a fresh scratch restore produces ZERO pg_restore errors; (3) the drill performs object-by-kind checks covering views, indexes, constraints, extensions and cron - row-count equality is explicitly insufficient and per-table expected==restored would have passed the failing restore; (4) the intended auth exclusion alignment is in place (auth.mfa_amr_claims data excluded alongside auth.sessions, so parent and child move as a unit). Audit's framing of the impact: access-request review behaviour is LOST (vAccessRequestsForReview absent) and auth referential integrity is WEAKENED (mfa_amr_claims_session_id_fkey silently absent). Blocked on Elazar's GO for the rail patch on whey; no Mars code change available to advance it.
-
Rail ownership corrected in the doc (bin-whey-cc withdrew the claim; our messages crossed and I had already endorsed it). Not bin-whey-cc: ENAMEL-12, filed 2026-07-31, carries an ownership escalation nw-whey-cc raised 2026-07-30 that has been blocked on Elazar for 22 days - nw-whey-cc is lane-correct and HOLDING, not declining. Settled split per the pre-existing nw/bin delegation rule: nw-whey-cc owns /opt/evolutiva-backups and the evolutiva-backup@* / evolutiva-restore-drill@* units (host service = nw lane); bin-whey-cc holds VERSION ownership of run.sh, restore-drill.sh, mark-failed.sh (versioned files = bin lane). Registration to bin-venus-cc under nw-whey-cc on their acceptance; today's patch lands under their ownership. THE PATTERN, third instance today: the answer was already on file and nobody read the file - same as the three contradictory cadence numbers and the paper-backup fact that retired the RPO analysis. Every expensive thing today was a fact that existed and was not looked up, not a wrong analysis.
-
coder-mars-ca / coder
-
coder-mars-cc / coder
-
coder03-mars-ca