fix(delete-user-data): kit/extension parity – kit failures are logged as HTTP 200 with no error severity #3251

delete-user-data kit/extension parity. Priority: medium. Function failures don't show up as errors, which is why #3250 goes unnoticed.

Difference

• Extension (1st gen): a thrown error is logged at ERROR severity, followed by finished with status: 'error' (DEBUG). A timeout logs only finished with status: 'timeout' (DEBUG).
• Kit (2nd gen): Cloud Run records the request as HTTP 200. The stack trace goes to stderr with no severity. A timeout shows up as 200 at INFO. Alerts or error-rate metrics keyed to function failures never fire.
• Error Reporting groups the thrown error in both, from the stack trace. Neither reports timeouts.

Reproduced

The functions framework itself returns 500 when a handler throws, so the 200 comes from the 2nd gen platform with retries disabled. The kit can't change the status code, but it can control how failures are logged.

Code

• Extension: triggers at index.ts#L59, #L117, #L203. 1st gen reports the failure status itself.
• Kit: the handlers pass errors through with no logging (index.ts#L112-L135).

Resolution

Wrap the three handlers so they log any error at ERROR severity and then rethrow. Keep the stack out of that entry's message, or Error Reporting counts each failure twice. In the README, note that 2nd gen request status doesn't reflect failures, and recommend log-based alerts (including the timeout request log, which a handler can't catch).