Skip to content

feat(functions): Implement TaskQueue Scopes#3210

Open
inlined wants to merge 6 commits into
firebase:mainfrom
inlined:feat/task-queue-scopes
Open

feat(functions): Implement TaskQueue Scopes#3210
inlined wants to merge 6 commits into
firebase:mainfrom
inlined:feat/task-queue-scopes

Conversation

@inlined

@inlined inlined commented Jul 9, 2026

Copy link
Copy Markdown
Member

Description

This PR introduces Task Queue Scopes to the Firebase Admin SDK functions module. It decouples the legacy backward-compatible string-to-scope migration logic from the stateless client and isolates it inside the API wrapper layer (TaskQueue).

Key Changes

  1. API Wrapper Retry & Upgrade (TaskQueue):
    • TaskQueue.enqueue() and delete() now capture 404 errors for legacy string parameters ('extensionOrKit' scope).
    • On a 404 error, they automatically retry using a temporary kit scope.
    • If the retry succeeds, the wrapper mutates the stateful scope to 'kit' and logs a legacy targeting warning.
  2. Immediate Self-Targeting Warning:
    • Matches targeting parameters against process.env.EXT_INSTANCE_ID and process.env.KIT_INSTANCE_ID at construction time.
    • If self-targeting is detected, it logs an immediate deprecation/performance warning and mutates the scope immediately to 'extension' or 'kit', bypassing unnecessary 404 fallback call roundtrips.
  3. Design style: chose to make the migration logic part of the API type and not the API internals type to more obviously collect what is transitionary/migration logic that can be removed later
  4. Unit Tests:
    • Added unit tests verifying scope resolves to global if no environment variables are set.
    • Added unit tests verifying self-targeting warnings and direct namespaced resolution for both extensions and kits.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a new FunctionScope type to represent the scope of a function in a task queue, deprecating the legacy extensionId string parameter. It updates FunctionsApiClient, Functions, and TaskQueue to support these scopes (including current, global, extension, and internal kit scopes) with fallback logic for migration, and adds comprehensive unit tests. The review feedback highlights a few issues and improvement opportunities: correcting a typo ('peformance') and an invalid scope value ({ scope: "self" } instead of { scope: "current" }) in warning messages (and their corresponding tests), removing a redundant type check in TaskQueue, and improving type safety in FunctionsApiClient by avoiding an as any cast through discriminated union narrowing.

Comment thread src/functions/functions.ts
Comment thread src/functions/functions.ts
Comment thread src/functions/functions.ts Outdated
Comment thread test/unit/functions/functions-api-client-internal.spec.ts Outdated
Comment thread src/functions/functions-api-client-internal.ts Outdated

@lahirumaramba lahirumaramba left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for submitting this!
LGTM! Added a couple of comments.

functionName: string,
extensionIdOrScope: string | FunctionScope = { scope: 'current' }
): TaskQueue<Args> {
const scope: FunctionScope = typeof extensionIdOrScope === 'string'

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we use FunctionScope will that get rid of the as any casts?

scope?: InternalFunctionScope
): { resourceId: string; extensionOrKitId?: string } {
if (typeof scope === 'undefined') {
return this.resolveResourceId(resourceId, { scope: 'current' });

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use a default parameter for scope and skip this recursive call?

private resolveResourceId (
  resourceId : string ,
  scope : InternalFunctionScope = { scope: 'current' }
)...

* @param id - The ID of the task to delete.
* @param functionName - The function name of the queue.
* @param extensionId - Optional canonical ID of the extension.
* @param scope - Optional FunctionScope configuration.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we get a TW review on these new docstrings, please?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants