fix(firestore-vector-search): stop double-prefixing task queue names - #3118
Open
IzaakGough wants to merge 2 commits into
Open
fix(firestore-vector-search): stop double-prefixing task queue names#3118IzaakGough wants to merge 2 commits into
IzaakGough wants to merge 2 commits into
Conversation
The queue names defaulted to kit-<instance id>-<function>, and the Admin SDK prepends that prefix again from FIREBASE_KIT_INSTANCE_ID, so the backfill and update triggers enqueued onto kit-<id>-kit-<id>-<function> and failed with "Queue does not exist". The four *_QUEUE_NAME settings now take the deployed function name without the prefix. The new test drives the real Admin SDK against a local Cloud Tasks emulator host and asserts the URL it produces; nothing covered the queue names before.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request fixes an issue where backfill and update task dispatches failed with a "Queue does not exist" error due to double-prefixing of queue names. The queue names are updated to use the unprefixed deployed function names, and corresponding tests are added. Feedback on the new test file suggests checking if the Firebase app is already initialized before calling initializeApp and cleaning up modified environment variables in the afterAll hook to prevent test side effects.
…tial Under the default credential the Admin SDK reaches for application default credentials while building the task payload, so the test only passed on a machine that had run `gcloud auth`. The emulator path never uses the credential; it sends an "owner" token.
IzaakGough
marked this pull request as ready for review
September 4, 2026 14:19
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Same defect as #3113, in a second kit.
What was broken
The four queue names defaulted to
kit-<instance id>-<function>, and the Admin SDK prepends that prefix again fromFIREBASE_KIT_INSTANCE_IDinresolveResourceId(). The backfill and update triggers enqueued ontokit-<id>-kit-<id>-<function>, so a backfill or a configure-time update dispatched nothing.What changed
resolveQueueNames()and the four*_QUEUE_NAMEparam defaults now use the bare export names. Those settings still work as overrides, but they name the deployed function rather than the fully-qualified queue. README and changelog say so.How it was verified
tests/task-queues.test.tspointsCLOUD_TASKS_EMULATOR_HOSTat a local server and drives the real Admin SDK throughhandleBackfillTrigger,handleUpdateTriggerandhandleInit, asserting the queue URLs. All three fail on the old code with the doubled prefix and pass on the new one. Twoexport-configtests pin the defaults and that an explicit override is kept verbatim.Nothing covered the queue names before. Not exercised here: a live deploy.