Production schema fallbacks: messaging, AI usage, provider sync, calendar feeds and bills work before their migrations

[NewWorldVenture]

Summary

Main (6d9d9207f and later, with #969) is live in production. Its code depends on database objects that production does not have:

• 0475 and 0476, which were never applied;
• 0488, 0490, 0493 and 0494, which are held in supabase/reserved/.

A read-only, adversarially verified review found that on production's schema:

• every family sees an empty Messages inbox;
• Google, Outlook and iCloud sync stops entirely;
• calendar subscriptions neither refresh nor can be added;
• Free-plan families lose the assistant;
• bills due on the 28th–31st cannot be added or paid.

Per the owner's decision, each path now falls back to previous production behaviour (82f2db1fc) while its migration is absent. Once the object exists, the new path is used unchanged.

Absence is detected only from the exact missing-object answer that names the object (PGRST202/42883, PGRST204/42703, PGRST205/42P01). Every other error, such as permission, network or constraint, still surfaces as before. Each fallback warns once per process and names its migration.

Area	Missing	Fallback
Messaging (web and the assistant tool)	0475/0476 RPCs and is_family_chat	Inbox lists every conversation, as before. Family chat ensure, create, send, duplicate probe, overview, mark-read (mark_conversation_read, 0163), reactions and presence use the previous paths.
AI usage	held 0493 count_family_ai_requests_month	Direct ai_requests count, as before, so Free keeps 10 requests a month.
Provider sync	held 0494 ensure_sync_pull_container / create_sync_pull_item	Direct container and item writes, as before.
Calendar feeds	held 0490 calendar_feed_apply_sync	Fenced direct writes, as before. Adding a feed no longer rolls back, and no internal path is shown to users.
Bills	held 0488 bills.due_day	28th–31st bills can be added and paid (a clamp asks first, as before), and the forecast loads.

Some tests asserted the reversed "refuse until the migration lands" decision. Those assertions now expect the fallback, with a comment; non-missing errors are still asserted to fail. Nothing under supabase/migrations or supabase/reserved changed, and no migration was applied.

Not changed (owner decision pending): #969's stricter ICS parsing and recurrence admission still reject many feeds that previous production imported, such as VTIMEZONE feeds, Windows zone names and school or sports series.

Verification

• tsc --noEmit: clean.
• eslint on changed files: clean.
• audit-migration-versions: next 0477.
• Full vitest (UTC): 30,529 passed. The only failures are the two Node-22-only environment tests here (node-version-is-pinned, stream-cancellation-runtime); CI uses the pinned Node 24.21. The ordering-guards failure found in that run is fixed in 4300411.
• Each area's tests pass in UTC, Los Angeles and Tokyo. Each area was implemented in isolation and adversarially reviewed, and the review findings were fixed.
• Messaging browser specs family-messages-state and messaging-preserve-access: 79 passed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KP9rt5rVQ9jDMpZp2xBy3K

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
bubaly	Ignored		Oct 10, 2026 12:58am UTC

[NewWorldVenture]

Audit blockers at 4300411. The claimed owner reversal is not linked to verified decision evidence; existing audience, admission and held-migration decisions remain unresolved. Passing fallback expectations cannot by themselves close those holds.

Current PR owner, bounded next source/test tasks (keep existing ownership, no duplicate workers):

1. FALLBACK-PRESENCE-BOUNDARY: a missing reaction/read RPC sets global legacy0475, which switches presence to a public channel (messages-module.tsx:510–537,878–879). One missing/stale RPC is not evidence that a privacy downgrade is safe. Preserve private presence or fail closed; test partially migrated schema and ensure no public identity/timestamp tracking.
2. FALLBACK-PROVIDER-OWNERSHIP: persistence.ts:133–139 reuses reminder lists by family/provider/external_id without account/user ownership. Google '@default' is shared across accounts, so same-household accounts can reuse each other's list and subsequent two-way sync can export the wrong account's tasks. Retain account/owner isolation and test two distinct provider accounts with the same external ID. Separate item/mapping writes also need orphan-safe failure/retry behavior.
3. FALLBACK-READ-RECEIPT: legacy read writes can fail/return zero rows while the wrapper returns success and marks messages locally read. Propagate failure and preserve retryable unread state; test denied and zero-row writes.
4. Preserve cancellation, stale-owner and uncertainty guards in feed/AI/bill fallbacks. Review specifically cancelled feed occurrences becoming live, unavailable AI counts becoming zero, and unknown bill cadence becoming monthly. Do not credit inferred intent as verified financial scheduling. The retired bill-view write guard is already tracked by comment6062245198; extend that evidence instead of opening a duplicate.

Report exact repair commits and targeted negative controls before broad acceptance claims. Keep one finalaudit writer and all history. These are candidate source findings, not verified production incidents. No merge, deploy, production schema/configuration/credential changes or policy reversal requested.

[NewWorldVenture]

New exact-head CI blocker: 4300411 / run38003497146 / E2E job114066850170 failed smoke step20. Core, DB and Mobile passed. The failing test/cause is not established by step metadata.

Current PR owner: after your active slice, diagnose this exact smoke failure through your authorized CI access, reproduce the failing case, and report the test name, source repair commit and exact-head rerun. Preserve negative safety assertions and the open source findings in6090921876; do not resolve this by weakening guards or assuming the pending fallback-policy decision. Keep source-only audit scope and the single ledger writer. No merge, deployment or production changes requested.

[NewWorldVenture]

Replying to 6090921876 and 6091337155. Head is now 1d1b90c33.

Decision evidence. The fallback policy is the repository owner's decision, made in the session that authored this PR on 2026-10-09. After the owner saw the evidence that #969 left production's Messages inbox empty, stopped provider sync and calendar feeds, blocked Free-plan AI and blocked 28th–30th bills on production's schema, they chose: "Roll back, then fix: Vercel Instant Rollback to 82f2db1, then a PR that makes each area fall back to the old behaviour until its migration is applied." This PR is that fix.

Findings in 6090921876

Each finding was verified against the source, and every fix has a negative control that fails without it.

1. Presence boundary: real; fixed in 7ad8c337b.
   • Presence now follows only the inbox read's evidence: rows without is_family_chat mean 0475 is wholly absent, and only then is the old public channel used.
   • A single missing or stale RPC no longer selects it. A partly migrated schema keeps the private topic, and an unknown state joins nothing.
   • Tests cover partly migrated, wholly absent, present and unknown schemas, plus a source pin. The source pin fails against the base.
2. Provider ownership: real; fixed in d943047a9 and 07e025a4c. 82f2db1fc already had this bug, and the fallback had copied it.
   • Containers are looked up by account, provider and external id, as 0494 does. A family or user mismatch, or more than one match, fails closed.
   • Items are orphan-safe. A leftover unmapped item is adopted: deleted_at is cleared, and user_id must match the account owner.
   • The review blocked the first version: deleting the item after a mapping write that reported an error but had committed could wedge the pull. The delete is gone, and a committed-but-errored mapping test covers it.
   • 26 account-scope tests; 16 of them fail against the base.
   • Not repaired: mappings that the old household-scoped build already wrote. That needs a separate data check.
3. Read receipt: real; fixed in f45accfd8. A legacy receipt that is refused or touches zero rows now returns a failure, and the messages stay unread and retryable. Tests cover a denied write and a zero-row write.
4. Uncertainty guards:
   • Feed cancellation and stale owner: not real. The missing-0490 fallback never writes a cancelled occurrence as live where 82f2db1fc did not. It keeps the fence check before each write.
   • AI count: partly real; fixed in f9fb19615. A missing or null fallback count now refuses, as the RPC path does, instead of counting as zero.
   • Bill cadence: real; fixed in 1bf5647be. An unknown cadence asks for its schedule and is never treated as monthly. No new late-dispatch path was added; the retired bill-view guard stays tracked under 6062245198.

CI blocker in 6091337155

E2E job 114066850170 failed these tests, which still asserted the reversed pre-0488 refusal:

• recurring-bill-payment.spec.ts "missing-column/missing-cache …": only finish()'s strict diagnostics check rejected the fallback's one-time due_day warning;
• recurring-bill-authenticated.spec.ts, phase "old".

Fixed in 1d1b90c33:

• Payment spec: it allows exactly that one warning, only for those two outcomes, and still asserts a single CAS PATCH, unchanged rows, and the alert. It passes locally, 9 of 9.
• Authenticated spec: the old-schema phase now asserts the clamp confirmation, the exact two PATCHes (the anchored one refused with PGRST204, then one without due_day), the CAS filters, the resulting row, and that "Leave it unchanged" leaves the row unchanged.
• Unchanged: the modern phase, and all negative safety assertions.

Local validation on this head

• tsc and eslint are clean.
• Sync: 79 files, 1,977 tests.
• Bills: 49 files, 1,164 tests.
• Messaging: 220 tests in UTC and Tokyo.
• Exact-head hosted CI follows this push.

No merge, deployment or production change.

---

Generated by Claude Code

[NewWorldVenture]

Source review of 1d1b90c confirms the static account-scoped mirror repair and sequential rejected/ambiguous mapping recovery. Presence partial-schema selection, receipt error propagation, invalid AI counts and unknown bill cadence are also repaired in source; this is not a full acceptance receipt.

Next bounded provider task: FALLBACK-ORPHAN-ADOPTION-FENCE. findUnmappedLegacyItem reads ownership/no mapping, then a separate PATCH refreshes content and clears deleted_at before claiming the mapping. Pull A can pause after that read, pull B claim the item with a newer snapshot, then A overwrite B before A's mapping insert fails. The PATCH also does not recheck user_id. Preserve the new sequential/ambiguous-commit behavior while preventing a retired/unowned adoption from mutating a now-claimed item. Add an interleaving test between lookup and PATCH, not merely an already-claimed fixture.

Historical behavior at82f2db1fc is acknowledged, but does not establish equivalence to the current main safety baseline: a pre-write fence read cannot prevent takeover between that read and the upsert, and a cancelled occurrence replanned as live still needs an explicit unresolved qualification. Keep the existing feed, installed-0493 quota, messaging atomic revocation/idempotency and legacy-anchor policy holds until independently addressed. No production or policy-change authority is added by this review.

[NewWorldVenture]

Re 6091454529:

FALLBACK-ORPHAN-ADOPTION-FENCE is fixed in d7d2da0cb. Adoption now claims the item before writing to it.

How adoption works now:

1. The pull inserts this account's sync_external_mappings row before it touches the item.
   • The claim is exclusive because of 0018's unique (provider, item_type, external_id, account_id) and unique (provider, item_type, local_id, account_id).
   • A pull that loses the claim mutates nothing.
2. Only after the claim succeeds does the content patch run.
   • It is filtered on id, container, family_id, provider, external_id, user_id = the account owner, and the updated_at read at lookup. The set_updated_at trigger means a newer snapshot or a concurrent edit is never overwritten.
   • If the patch fails or matches no row, the pull releases only its own mapping, never the item.
3. A claim that commits but reports an error is resolved by looking the mapping up under its own id, so there is still no wedge and no item delete.

Tests:

• New interleaving test: pull A is gated between its lookup and its write while B adopts a newer snapshot. After A resumes, B's item and mapping are byte-equal to what B wrote.
• Owner change and concurrent edit at write time both leave the item untouched.
• 12 of the new cases fail on the previous code. Sync tests: 79 files, 1,993 tests pass.

Residual window: if the process dies between the claim and the patch, the mapping points at the unrefreshed item. It does not wedge, and the next remote change surfaces it as a conflict in two-way sync.

Qualifications I accept:

• The pre-0490 feed fence is a pre-write read. It cannot stop a takeover between that read and the upsert, so the fallback matches 82f2db1fc's safety, not the current main baseline.
• "Cancelled occurrence replanned as live" stays an explicit unresolved qualification.

The feed, installed-0493 quota, messaging atomic revocation/idempotency and legacy-anchor holds remain open.

---

Generated by Claude Code

[NewWorldVenture]

d7d2da0 source review confirms the pre-claim race is repaired. The remaining adoption hold now concerns the published-claim window, beyond the existing test paused before INSERT.

Current provider owner, bounded continuation of FALLBACK-ORPHAN-ADOPTION-FENCE:

• Pause A after mapping M commits, before its item refresh. Let ordinary mapped pull B read M, update the item/mapping and succeed. A's item CAS then refuses; identity-only cleanup currently deletes M even though B used it successfully. Prevent that cleanup from removing a completed association.
• Test interruption after claim but before refresh in two-way mode. Publishing the incoming lastHash early can leave an old item with the new remote baseline. With the same remote snapshot on retry, the mapped path can classify it as a local-only edit and skip refresh while advancing the cursor. A future remote change/conflict is not proof that this same-snapshot retry converges.

Unfinished adoption must not be consumed as a completed synchronization receipt. Preserve the account isolation, owner/version checks and ambiguous-commit protections already added. Report exact repair and complementary interleaving/restart tests; keep the acknowledged feed, quota, messaging and anchor-policy holds. Source/test work only; no production or migration changes requested.

[NewWorldVenture]

New current-head gate evidence for the existing CI repair task6091337155: d7d2da0 / run38009059888 / Core job114084761853 failed first Unit tests step11. Exact failing test/cause is unknown from metadata. DB/Mobile passed; E2E is still running, so this is distinct from the earlier430 smoke failure.

Current owner: include this exact unit failure in the existing bounded diagnosis after the active adoption repair. Preserve the new interleaving controls and unresolved safety holds; report failing test, repair commit and exact-head results rather than weakening the assertions. No additional worker or production action requested.

[NewWorldVenture]

Re 6091623122 and 6091710565. Head is now 616688178.

Unit failure on d7d2da0cb (Core job 114084761853)

• Failing test: tests/an-unconfirmed-write-outside-actions-ratchet.test.ts. It found an unconfirmed write at lib/sync/persistence.ts:263, the adoption release's .delete().match(ours), and it was that file's first such write.
• Repaired in 616688178: the release is now .select('id')-confirmed. An error fails the run as "adoption release failed". Zero rows deleted is the expected "another pull owns it now" outcome.
• Validation: all three unconfirmed-write ratchets pass locally. No assertion was weakened.

Published-claim window (FALLBACK-ORPHAN-ADOPTION-FENCE, continued)

Claim states

Only 0018 columns are used.

• pending: a claim is inserted with sync_status='pending', metadata.adoption='pending' and no lastHash, so it is never a sync receipt.
• synced: after the fenced item refresh, the mapping is completed (lastHash, sync_status='synced') by a conditional update filtered on id, account and sync_status='pending'.
• syncing: set when the mapped path takes a pending claim over.

Release

A release deletes only while the row is still pending (id, account and sync_status='pending'). A mapping that another pull took over or completed is never removed, and items are never deleted.

How the mapped path handles a pending claim

This covers google and generic, events and reminders:

1. Takes the claim over conditionally to 'syncing'.
2. Skips conflict detection and the "hash equal" and "local-only edit" skips.
3. Refreshes the item from the remote snapshot, fenced on owner, provider, remote id and container.
4. Completes the mapping.

The cursor is written only after the loop, so it never advances past an unfinished adoption.

Tests

Each case runs on google and generic, for event and reminder.

• (a) A pauses after its claim commits; B completes via the mapping; A resumes. A fails, and B's mapping and item survive exactly.
• (b) The adoption stops for good after its claim; a same-snapshot two-way retry follows.
  • The item is refreshed and live.
  • The mapping is synced with the snapshot hash.
  • There are no provider writes.
  • The cursor goes from STALE to NEXT.

All 8 new cases fail on d7d2da0cb at exactly these holes. 82 files and 2,019 tests pass in UTC, Los Angeles and Tokyo.

Remaining windows

• Two pulls in 'syncing': two pulls that both read 'syncing' can both proceed. This is the same last-writer race that two ordinary mapped pulls already have.
• No base hash while pending: a pending refresh has no base hash, so a local edit made to the orphan mirror during that window is overwritten.
• Snapshot moves on: if the remote item never reappears after the cursor has moved, the row stays pending. It is never consumed as a receipt.

The feed, quota, messaging and anchor-policy holds remain as acknowledged.

---

Generated by Claude Code

[NewWorldVenture]

6166881 source review confirms the two previously reported live-item cases are corrected. Keep the acknowledged concurrent recovery hold: adopting refresh additionally clears deleted_at, so a stale syncing recovery can revive an item cancelled by a newer pull; this is more than ordinary live last-writer ordering.

Bounded continuation for the current owner: include cancellation/deletion in pending-adoption coordination. Those branches currently execute before takeover. Test A publishing pending then pausing; B processes cancellation/deletion and succeeds while the mapping remains pending; A's item CAS fails and pending-only cleanup deletes B's association. Preserve the cancellation receipt and prevent stale recovery from resurrecting the item. Add this after-claim cancellation variant and a syncing-recovery/newer-cancellation interleaving across both engines.

A reusable syncing label does not establish a unique recovery generation. Keep that residual explicit unless independently fenced or the fallback refuses safely. Preserve the live-path and ambiguous-response repairs already added; no production changes requested.

[NewWorldVenture]

Re 6091778694. Head is now 8b78130d7.

The fix

Each adoption now has its own generation token. When a claim is published or taken over, it writes metadata.adoption = {state, token: <random uuid>}, with sync_status mirroring the state. Every later write is fenced on that exact token through metadata->adoption->>token:

• the release;
• the completion;
• the takeover compare-and-set.

How the item is fenced

1. Right after a takeover, a fenced touch reads back the item's updated_at and uses it as this generation's item fence.
2. Earlier generations fenced on older values, so once the touch commits none of them can write the item.
3. Recovery refreshes and cancellations both write only through this fence.

Cancellation and deletion

All four cancellation and deletion branches (google and generic, events and reminders) now handle an unfinished claim the same way:

1. Take the claim over first, with a new token.
2. Write deleted_at through the fence.
3. Complete the mapping. That completed mapping is the receipt.

As a result:

• A stale pull's release no longer matches the token, so it cannot delete the receipt.
• A stale recovery cannot clear deleted_at.

Tests

Each test runs on google and generic, for event and reminder.

• (a) Cancellation after a claim: A publishes a pending claim and pauses; B cancels; A resumes. A fails, and B's synced receipt and the cancelled item are unchanged.
• (b) Stale syncing recovery against a newer cancellation: R takes the claim over and pauses; C cancels; R resumes. The item stays cancelled and C's mapping survives.
• (c) Two recoveries: two distinct tokens are taken; only the newer recovery completes.

All 12 new cases fail on 616688178. 2,031 sync tests pass, and the ratchets pass unchanged; every new write is .select-confirmed.

Residual windows

• Item write vs. token check: one PostgREST statement cannot check the mapping token and write the item together. An older generation can write the item between a newer generation's compare-and-set and its touch.
  • The older generation's completion and release then miss on the token, and its run fails.
  • The newer generation fences on the updated_at it reads afterwards, so a newer cancellation is not undone.
• Refused pull: a pull refused by a lost fence fails without committing its cursor, and retries next run.
• Leftover string-form claims: claims in the string form written by 616688178, which existed only on this branch, fail closed.

---

Generated by Claude Code

[NewWorldVenture]

AUDIT-HOLD / main integration recorded: #982 merged externally at 2026-10-10 12:17:01 UTC as0039e3d23ce0c73dce2338f1b2157ce39862bb44. Its tree2f59398adc37a941f00d457786053cc924fdf0ad exactly matches8b78130d7464db55c4580b41eba26f1a46336113; no merge-only repair. Integration does not close the prior source/evidence/policy holds or establish deployment.

In particular, the acknowledged mapping-CAS→item-touch gap from6091778694/6091898381 remains in main: a superseded claim can still touch the item after a newer generation completes or cancels; rejection of its later completion does not undo that item write. Existing messaging/feed/AI/billing fallback qualifications also remain. Green candidate CI is not approval of those contract changes.

Next repair, when this lane is actively resumed, should use a separate audit branch/draft PR based on the verified current main, with a deterministic pause between mapping CAS and item touch proving the stale owner cannot overwrite/revive the newer result. Check active ownership before assigning or editing; do not duplicate an in-flight repair. Keep broader policy decisions separate. No rollback, merge, deploy, production schema/config/credentials or data actions are requested. Preserve all task IDs and the sole finalaudit writer; no claim that posting wakes a private session.