In the bigquery-firestore-export kit (@firebase/bigquery-firestore-export, on the kits branch), changing INSTANCE_ID after a first deploy creates a second BigQuery scheduled query and leaves the first one running and billable.
Cause
Every runtime name comes from the INSTANCE_ID param (kits/bigquery-firestore-export/src/config.ts): the topic the lifecycle task creates, the topic the trigger subscribes to, the topic Data Transfer notifies, and the extInstanceId field stamped on the config document. The key in the instances map only names the deployed resources, so the two can differ without anything failing.
handleUpsertTransferConfig looks up the existing config with where("extInstanceId", "==", instanceId) (src/handlers.ts). Once INSTANCE_ID changes, that query misses and the lifecycle task creates a new scheduled query. The old one stays enabled and scheduled, notifying a topic with no subscriber, with its own Firestore documents alongside. Nothing reports it.
What happens
Deployed on a live project with map key robusta and INSTANCE_ID=robustb, which worked end to end. Correcting INSTANCE_ID to robusta produced a second transfer config, and the first was left enabled with a next run scheduled.
Fix
Most likely documentation, since nothing links an old config to a new id. A CLI-side check that INSTANCE_ID matches the instance map key would catch the mismatch, since the CLI knows the key and the kit does not.
In the
bigquery-firestore-exportkit (@firebase/bigquery-firestore-export, on thekitsbranch), changingINSTANCE_IDafter a first deploy creates a second BigQuery scheduled query and leaves the first one running and billable.Cause
Every runtime name comes from the
INSTANCE_IDparam (kits/bigquery-firestore-export/src/config.ts): the topic the lifecycle task creates, the topic the trigger subscribes to, the topic Data Transfer notifies, and theextInstanceIdfield stamped on the config document. The key in theinstancesmap only names the deployed resources, so the two can differ without anything failing.handleUpsertTransferConfiglooks up the existing config withwhere("extInstanceId", "==", instanceId)(src/handlers.ts). OnceINSTANCE_IDchanges, that query misses and the lifecycle task creates a new scheduled query. The old one stays enabled and scheduled, notifying a topic with no subscriber, with its own Firestore documents alongside. Nothing reports it.What happens
Deployed on a live project with map key
robustaandINSTANCE_ID=robustb, which worked end to end. CorrectingINSTANCE_IDtorobustaproduced a second transfer config, and the first was left enabled with a next run scheduled.Fix
Most likely documentation, since nothing links an old config to a new id. A CLI-side check that
INSTANCE_IDmatches the instance map key would catch the mismatch, since the CLI knows the key and the kit does not.