delete-user-data kit tracking issue #3249

Tracks parity between the delete-user-data extension (0.1.30) and the @firebase-function-kits/delete-user-data kit.

How it was tested: both deployed side by side on a test project with matching configs, then compared on data deleted, events, Pub/Sub messages, logs, runtime settings, install and uninstall. Kit tested at kits @ fcdd555, installed three ways: the README's manual setup, functions:kits:install, and ext:migrate.

Sub-issues are ordered by priority, highest first.

Issues labelled decision need a call: change the kit, or record the difference as accepted in the below "Decisions" section.

Decisions

• decision(delete-user-data): kit/extension parity – kit continues after an Eventarc publish failure, the extension aborts #3254: Eventarc publish failures are logged as warnings and deletion carries on, where the extension aborted. Accepted. Documented in docs(delete-user-data): note that a failed event publish doesn't stop deletion #3321.
• decision(delete-user-data): kit/extension parity – CLI-installed kit runs Node 24, extension runs Node 22 #3261: the runtime follows the host codebase, so functions:kits:install and ext:migrate deploy on Node 24 where the extension ran nodejs22. Accepted.

Intentional Differences

• 2nd gen only: all three functions are 2nd gen, so clearData listens on the 2nd gen Auth event google.firebase.auth.user.v2.deleted instead of the 1st gen user.delete trigger.
• Instance id and topics: the instance id comes from firebase.json (FIREBASE_KIT_INSTANCE_ID), and the Pub/Sub topics are kit-<id>-discovery / kit-<id>-deletion instead of ext-<id>-*.
• Region: there's no install-time location. Set it with setGlobalOptions({ region }); the functions:kits:install and ext:migrate templates do this from FUNCTION_DEFAULT_REGION. Otherwise the functions deploy to us-east1.
• Ingress: all three functions are always ALLOW_INTERNAL_ONLY, the extension's default. The extension's install-time ingress setting doesn't carry over: setGlobalOptions({ ingressSettings }), which ext:migrate uses for it, doesn't change the kit's ingress (fix(delete-user-data): kit/extension parity – kit silently skips deletions under load (concurrency 80 OOM) #3250).
• Eventarc channel: the kit doesn't create the channel. It must exist before EVENTARC_CHANNEL is set.
• Failure status: 2nd gen request logs show HTTP 200 for failed and timed-out runs, and there's no status: 'error' / 'timeout' line. Failures only show up in the logs.
• When param values are checked: the extension checked each value once, when it was installed or reconfigured. The kit has no install step, so it checks the same values every time it's deployed or loaded in the emulator, and a bad value fails that deploy. It accepts and rejects the same values as the extension, option labels included (once fix(delete-user-data): reject invalid select and regex param values at deploy #3278 lands).
• Eventarc publish failures: logged as warnings, and deletion carries on. The extension aborted, skipping auto-discovery and SEARCH_FUNCTION (decision(delete-user-data): kit/extension parity – kit continues after an Eventarc publish failure, the extension aborts #3254).
• Node runtime: follows the host codebase. functions:kits:install and ext:migrate write Node 24; the extension ran nodejs22 (decision(delete-user-data): kit/extension parity – CLI-installed kit runs Node 24, extension runs Node 22 #3261).