Confusing error when a lifecycle hook targets a task queue function whose name is not a valid queue ID

[IzaakGough]

Small polish, not a correctness bug. Failing here is correct, since process_task cannot be a Cloud Tasks queue ID. The error just arrives as a raw API error rather than one naming the function.

Environment info

firebase-tools: 15.27.0

Platform: macOS

Test case

A task queue function whose name contains an underscore, targeted by a lifecycle hook.

import { onTaskDispatched } from "firebase-functions/v2/tasks";
import { afterFirstDeploy } from "firebase-functions/lifecycle";

export const process_task = onTaskDispatched(async () => {
  // ...
});

afterFirstDeploy({ task: { function: "process_task" } });

Steps to reproduce

1. Deploy the codebase.
2. Run firebase functions:lifecycle:run afterFirstDeploy default.

Actual behavior

HTTP Error: 400, Queue ID "process_task" can contain only letters ([A-Za-z]),
numbers ([0-9]), or hyphens (-). Queue ID must be between 1 and 100 characters.

executeTaskQueueHook in src/deploy/functions/release/lifecycle.ts derives the queue name from the function id (line 164) and enqueues against it (line 195) without checking it is a legal queue ID. The message quotes the name, so it is workable, but it talks about a queue ID when the thing to change is the function name.

Suggested fix

Call cloudtasks.isValidQueueId (added in #10834) before enqueuing and throw a FirebaseError saying the queue was never created and the function needs renaming.

Reachability

Low. #10834 rejects these names at deploy time, so this only affects functions deployed by an older CLI, reached via functions:lifecycle:run, which builds its backend without running endpointsAreValid. firebase deploy catches hook failures and logs a warning, so it does not fail there.

I confirmed the Cloud Tasks responses with direct API calls but have not deployed a function end to end.

[IzaakGough]

Closing this. The existing error already quotes the offending name and states the rule, so it is actionable as-is, and #10834 rejects these names at deploy time anyway. Not worth tracking.