fix(backend): unconfigured recordings bucket deadlocks account deletion (6 users stuck on prod)

[kodjima33]

The bug (live on prod, right now)

Account deletion is failing for every user who requests it, and their data is being retained.

BUCKET_MEMORIES_RECORDINGS was never wired into the backend Helm charts (it's absent from prod_omi_backend_listen_values.yaml, the dev values, and .env.template), so memories_recordings_bucket resolves to None in prod. delete_all_conversation_recordings calls .bucket(None), and listing raises:

ValueError: Cannot determine path without bucket name.

That purge is a required step, so the raise aborts background_wipe_user_data before users_db.delete_user_data(). The wipe is marked wipe_failed, the reconciler re-enqueues it, and it fails again — forever. Prod logs (last 24h):

ERROR:services.users.account_deletion:delete_account purge recordings failed for <uid>: Cannot determine path without bucket name.
ERROR:services.users.account_deletion:delete_account background wipe failed for <uid>: required derived purge failed: conversation_recordings
INFO:services.users.account_deletion:delete_account reconciliation: re-enqueued 6, skipped 0

Six uids are stuck in that loop. Their Firestore data (conversations, memories, chats) is still there after they asked to be deleted.

Root cause

An unconfigured bucket was being treated as a purge failure. A permanent config gap therefore became a permanent block on an irreversible-but-requested deletion.

The fix

An unconfigured bucket now means "nothing to purge" and returns cleanly — uploads resolve the same bucket name, so a deployment without it cannot have stored recordings.

A real GCS failure still raises and still blocks the irreversible Firestore wipe. That contract is deliberate (retry rather than partially wipe) and is unchanged — test_gcs_failure_blocks_firestore_wipe still passes untouched.

Verification (real path, live prod GCS, prod service account)

• Replaying the pre-fix function body with the bucket unset and one of the actual stuck uids reproduces the prod log line byte-for-byte: ValueError: Cannot determine path without bucket name.
• With the fix, the same call returns cleanly → required_failures is empty → the wipe proceeds to the Firestore delete.
• With the bucket configured, the purge still lists live gs://memories-recordings and deletes the {uid}/ prefix (exercised against a uid with no objects, so nothing was deleted).
• New regression test fails without the guard, passes with it.
• backend/test.sh: 564 test files, 0 failures.

⚠️ Not merged — needs your sign-off

AGENTS.md requires explicit user sign-off for data deletion changes, and this one enables an irreversible Firestore wipe that is currently blocked. I've verified it end-to-end, but I'm not merging that class of change autonomously. The blast radius is only users who already requested deletion — this does not change who gets wiped, only whether the recordings step can veto the wipe.

⚠️ Config gap left open (deploy config — not mine to land)

BUCKET_MEMORIES_RECORDINGS is still missing from the Helm values. Consequences:

• Conversation recordings are not purged on account deletion. One legacy uid still has objects in gs://memories-recordings — if they delete their account, this fix skips their .wav files. (None of the 6 currently-stuck uids have objects there, so nothing is left behind for them.)
• The recordings feature is inert deployment-wide: upload_conversation_recording (consent-gated on store_recording_permission) and the has_recording endpoint both hit the same unset name.

Wiring the env var into the charts restores the purge and the feature. I left it alone because it's deploy config.

🤖 automated by hourly watchdog; opened for review, not merged.