chore(firestore-bigquery-export): bump firebase-admin to ^14.2.0 - #3127
Open
cabljac wants to merge 1 commit into
Open
chore(firestore-bigquery-export): bump firebase-admin to ^14.2.0#3127cabljac wants to merge 1 commit into
cabljac wants to merge 1 commit into
Conversation
![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 updates the firebase-admin dependency from ^13.6.0 to ^14.2.0 in kits/firestore-bigquery-export/package.json and updates the lockfile accordingly. However, this upgrade introduces a dual-instance hazard because @firebaseextensions/firestore-bigquery-change-tracker still depends on v13. This mismatch can lead to runtime errors since the nested v13 instance used by the change tracker will remain uninitialized. To resolve this, the change tracker should be updated to support v14, or the initialized Firebase instance should be passed directly to the tracker.
This was referenced Sep 7, 2026
cabljac
added a commit
that referenced
this pull request
Sep 7, 2026
…ase-admin 14 (#3133) The change tracker pins `firebase-admin` to `^13.2.0`. A consumer on firebase-admin 14 therefore installs a second copy of the SDK nested under the tracker, and that copy has its own app registry: the consumer's `initializeApp()` never reaches it. Every call the tracker makes through its own copy, which today is the backup write in `handleFailedTransactions`, fails with "The default Firebase app does not exist", the failure is logged as `failedBackupWrite`, and the rows meant for `backupTableId` are lost. Verified by loading both copies in one process against the published 2.1.0. The range was already widened to `^13.2.0 || ^14.0.0` on the `kits` branch (cc86630) but that landed at 2.0.4 and was never published; 2.1.0 was cut from `next` without it. This cherry-picks that commit onto `next` and releases it as 2.1.1 with a changelog entry. No source changes: the tracker only uses `getFirestore`, `firebase-admin/app` and `Timestamp`, all unchanged between 13 and 14, and the firebase-functions 6 it depends on already accepts admin 14. `npm ci` and `npm run build` pass. The jest suite needs live BigQuery and was not run. Unblocks the kit bump in #3127. --------- Co-authored-by: Izaak Gough <izaak.gough@invertase.io>
cabljac
added a commit
that referenced
this pull request
Sep 7, 2026
…ase-admin 14 (#3134) Follow-up to #3133. 2.1.1 widened the firebase-admin range to `^13.2.0 || ^14.0.0` but two things stopped it working on 14. First, firebase-admin 14 removes the namespaced API. The package still read `admin.apps` at import in `handleFailedTransactions` and `admin.firestore.Timestamp` in the partition converter, so wherever it resolved against admin 14 it threw `Cannot read properties of undefined (reading 'length')` at import. Every namespaced use, in shipped code, the test fixture and the tests, is now the modular API from `firebase-admin/app` and `firebase-admin/firestore`, which is identical on 13 and 14. Second, the package depends on firebase-functions `^6.3.2`, whose peer range for firebase-admin stops at `^13.0.0`. On a consumer running admin 14 npm therefore kept a nested admin 13 under the tracker regardless of the tracker's own range, and that nested copy has no default app. Under npm that nesting is also why 2.1.1 did not crash: `admin.apps` resolved on the nested 13. The range now accepts firebase-functions 7 as well; the package only uses its `logger`. Verified: build and the test tsconfig compile against admin 14.3.0 and functions 7.3.2; `converter.test.ts` passes (48) on that tree; the packed tarball installed into the firestore-bigquery-export kit on admin 14, followed by `npm dedupe`, collapses to a single admin copy, the tracker resolves the kit's app, and all 62 kit tests pass. An existing consumer shrinkwrap does not dedupe on its own, since the nested 13 still satisfies the new ranges, so the kit bump must dedupe explicitly. The kit pins firebase-functions `^7.3.3-rc.0`, which no stable range matches, so a nested firebase-functions 7.3.2 remains under the tracker until the kit moves to a stable 7.x; that only affects trace correlation on tracker log lines, not the admin app. The lockfile stays on admin 13 and functions 6 because under admin 14 the jest config cannot load the ESM-only `jose` that firebase-functions v2 pulls in via admin auth; that is a jest `transformIgnorePatterns` gap for a separate change. The live BigQuery suites were not run. Unblocks the kit bump in #3127.
cabljac
force-pushed
the
chore/kits-fbe-admin-14
branch
from
September 7, 2026 16:45
957a4ce to
aed3029
Compare
cabljac
marked this pull request as ready for review
September 7, 2026 16:50
firebase-admin 14.2.0 resolves the deployed kit function name prefix from FIREBASE_KIT_INSTANCE_ID when enqueuing onto a task queue. The change tracker moves to 2.2.0, the first release that runs on firebase-admin 14, so the shrinkwrap holds a single admin copy and the tracker sees the kit's app. An override pins the tracker's firebase-functions to the kit's own prerelease, which no stable range can match, so the shrinkwrap holds a single firebase-functions copy too.
cabljac
force-pushed
the
chore/kits-fbe-admin-14
branch
from
September 7, 2026 17:26
aed3029 to
793eefb
Compare
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
1 participant
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.
First layer of the Cloud Tasks write buffer stack. Bumps firebase-admin from ^13.6.0 to ^14.2.0 and the change tracker from ^2.1.0 to ^2.2.0, regenerates the shrinkwrap, and adds one override; no source changes.
The next layers enqueue onto a task queue by bare function name. firebase-admin 14.2.0 resolves the deployed
kit-<instance id>-prefix itself fromFIREBASE_KIT_INSTANCE_ID, which the Firebase CLI sets on every deployed kit function from 15.28.0, so the kit does not have to reconstruct the prefix.Tracker 2.2.0 (#3133, #3134) is the first release that runs on firebase-admin 14: earlier versions pinned admin 13 and used the namespaced API, so npm nested a second admin copy under the tracker with no default app and every backup write failed. The shrinkwrap now holds a single
firebase-admin@14.3.0, verified by resolvingfirebase-admin/firestorefrom the tracker's directory and callinggetFirestoreafter the kit'sinitializeApp. The kit pinsfirebase-functions ^7.3.3-rc.0, which no stable range in the tracker can match, so a rootoverridesentry pins the tracker's firebase-functions to the kit's own; the shrinkwrap holds a singlefirebase-functions@7.3.3-rc.0as well, so tracker log lines keep the kit's trace context.62 unit tests and
tsc -bpass on this layer; 89 on the top of the stack. Not verified against a live deploy.Part of #3031.