Package: @firebaseextensions/firestore-bigquery-change-tracker, src/bigquery/index.ts:146 on next.
this.bq = new bigquery.BigQuery();
this.bq.projectId = config.bqProjectId || process.env.PROJECT_ID;
new BigQuery() with no projectId leaves the client's internal {{projectId}} placeholder in place, and @google-cloud/common resolves it from Application Default Credentials on the first request. The assignment on line 146 overwrites that placeholder unconditionally. When the caller passes no bqProjectId and process.env.PROJECT_ID is unset, bq.projectId becomes undefined, auto-detection never runs, and every generated query references undefined.<dataset>.<table>.
PROJECT_ID is an extensions-only variable. A plain Cloud Function (gen1 or gen2) never has it. The Firebase CLI sets FIREBASE_CONFIG and GCLOUD_PROJECT only.
Who is affected: any consumer of the tracker that omits bqProjectId and is not an extension. The firestore-bigquery-export kit is not affected, it always passes bqProjectId (kits/firestore-bigquery-export/src/export-config.ts:191 falls back to projectID.value()). #3120 and 2.2.1 fixed the one kit-reachable variant of this (the update-view path dropped bqProjectId).
Suggested fix: only assign when a value exists, and prefer GCLOUD_PROJECT over PROJECT_ID as the env fallback.
const projectId = config.bqProjectId || process.env.PROJECT_ID || process.env.GCLOUD_PROJECT;
this.bq = projectId ? new bigquery.BigQuery({ projectId }) : new bigquery.BigQuery();
snapshot.ts:68 has the same bqProjectId || process.env.PROJECT_ID fallback and should follow the same order. Both initializeLatestView call sites now pass bqProjectId, so that one is defensive only.
Found during the adversarial review of #3137. Related: #2779 proposes a GOOGLE_CLOUD_PROJECT fallback, which the CLI does not set either.
Package:
@firebaseextensions/firestore-bigquery-change-tracker,src/bigquery/index.ts:146onnext.new BigQuery()with noprojectIdleaves the client's internal{{projectId}}placeholder in place, and@google-cloud/commonresolves it from Application Default Credentials on the first request. The assignment on line 146 overwrites that placeholder unconditionally. When the caller passes nobqProjectIdandprocess.env.PROJECT_IDis unset,bq.projectIdbecomesundefined, auto-detection never runs, and every generated query referencesundefined.<dataset>.<table>.PROJECT_IDis an extensions-only variable. A plain Cloud Function (gen1 or gen2) never has it. The Firebase CLI setsFIREBASE_CONFIGandGCLOUD_PROJECTonly.Who is affected: any consumer of the tracker that omits
bqProjectIdand is not an extension. The firestore-bigquery-export kit is not affected, it always passesbqProjectId(kits/firestore-bigquery-export/src/export-config.ts:191falls back toprojectID.value()). #3120 and 2.2.1 fixed the one kit-reachable variant of this (the update-view path droppedbqProjectId).Suggested fix: only assign when a value exists, and prefer
GCLOUD_PROJECToverPROJECT_IDas the env fallback.snapshot.ts:68has the samebqProjectId || process.env.PROJECT_IDfallback and should follow the same order. BothinitializeLatestViewcall sites now passbqProjectId, so that one is defensive only.Found during the adversarial review of #3137. Related: #2779 proposes a
GOOGLE_CLOUD_PROJECTfallback, which the CLI does not set either.