In the bigquery-firestore-export kit (@firebase/bigquery-firestore-export, on the kits branch), a lifecycle task that fails does not fail the deploy, so a rejected reconfiguration leaves no sign that anything went wrong.
What happens
Clearing a PARTITIONING_FIELD that was previously set is not supported by the BigQuery Data Transfer API, and kits/bigquery-firestore-export/src/dts.ts throws for it deliberately. On a live project, firebase deploy still printed "Deploy complete!" and exited 0.
The failure stays inside the upsertTransferConfig task, which retried five times over 7m31s (30s, 60s, 120s, 240s backoff) before giving up at its maxAttempts: 5 (src/index.ts). The transfer config and its Firestore document were left at the last good state.
Two things make it worse than a one-off:
- It is sticky. The empty value stays in
.env, so every later deploy fails the same way, still silently, until the user restores a value that nothing tells them.
- The guard throws before any API call, so the error is deterministic and the five retries cannot help.
Fix
Log a warning and return instead of throwing on a request that is known to be unsupported, which at least avoids five pointless retries. Surfacing lifecycle-task failures at deploy time needs a channel back to the CLI and is not fixable in the kit alone.
In the
bigquery-firestore-exportkit (@firebase/bigquery-firestore-export, on thekitsbranch), a lifecycle task that fails does not fail the deploy, so a rejected reconfiguration leaves no sign that anything went wrong.What happens
Clearing a
PARTITIONING_FIELDthat was previously set is not supported by the BigQuery Data Transfer API, andkits/bigquery-firestore-export/src/dts.tsthrows for it deliberately. On a live project,firebase deploystill printed "Deploy complete!" and exited 0.The failure stays inside the
upsertTransferConfigtask, which retried five times over 7m31s (30s, 60s, 120s, 240s backoff) before giving up at itsmaxAttempts: 5(src/index.ts). The transfer config and its Firestore document were left at the last good state.Two things make it worse than a one-off:
.env, so every later deploy fails the same way, still silently, until the user restores a value that nothing tells them.Fix
Log a warning and return instead of throwing on a request that is known to be unsupported, which at least avoids five pointless retries. Surfacing lifecycle-task failures at deploy time needs a channel back to the CLI and is not fixable in the kit alone.