Firebase Cloud Functions returned 403 errors with missing auth context for 12 minutes after a redeploy that included a Firestore rules update. Root cause: Functions were deployed before Rules, creating a window where new function code ran against stale IAM/rules state. Fix: always deploy Firestore rules before Cloud Functions when both change in the same release.
Firebase Functions and Firestore rules are separate deployment artifacts that Firebase manages with separate IAM and configuration states. When both change in the same release and are deployed in the wrong order, there is a window where the function is live against an inconsistent backend state. This produced a 12-minute production outage on TrustSeal in which users could not verify trust claims.
A release included changes to both Firebase Cloud Functions and Firestore security rules. The deploy was run as a single firebase deploy command, which in practice deploys functions and rules in undefined order — in this case, functions deployed first.
For the 12 minutes between the functions deploy completing and the rules deploy completing:
Firebase Functions logs showed:
Error: missing auth context
HTTP response to client: 403 Forbidden
14 requests failed before the rules deploy completed and the auth context error disappeared.
Local emulator did not reproduce the failure. The Firebase emulator runs with a static, pre-loaded rules state and does not replicate the IAM propagation behavior of Firebase's production infrastructure. This is a documented divergence between emulator and production behavior.
Firebase maintains separate deployment pipelines for Cloud Functions (Cloud Run) and Firestore security rules (Firebase Security Rules engine). Each has its own propagation timeline after a deploy command completes.
When functions are deployed first:
When rules are deployed first:
The emulator divergence: The Firebase emulator loads rules at startup and holds them statically. It does not simulate IAM propagation delays or intermediate deployment states. A test passing in the emulator provides no signal about deployment ordering correctness in production.
| Time | Event |
|---|---|
| T+0 | firebase deploy run — functions deploy first |
| T+2m | Functions deploy complete — new code live |
| T+2m | First 403 error observed in Firebase logs |
| T+4m | Incident noticed — TrustSeal check button returning error |
| T+8m | Rules deploy completes (part of same deploy command, delayed) |
| T+12m | 403 errors stop — 14 total failed requests |
| T+15m | Root cause identified — rules-first deploy sequence established |
When only functions change (no rules):
firebase deploy --only functions
When only rules change (no functions):
firebase deploy --only firestore:rules
When both change in the same release:
# Step 1: Deploy rules first — let IAM state stabilize
firebase deploy --only firestore:rules
# Step 2: Deploy functions into stable rules environment
firebase deploy --only functions
Never use for combined rules + functions releases:
# DANGEROUS — undefined deployment order
firebase deploy
# or
firebase deploy --only firestore:rules,functions
The single firebase deploy --only firestore:rules,functions command deploys both targets but the ordering between them is not guaranteed by Firebase's CLI.
The Firebase emulator suite:
firestore.rules at emulator startupfirebase emulators:start arguments does not simulate production deploy orderThis failure class is emulator-invisible by design. It can only be caught by:
After any Firebase deployment that includes rules changes:
# After rules deploy — verify rules are active before deploying functions
firebase firestore:rules list # confirm rule version deployed
# After functions deploy — immediate functional test
# Run a test request and verify auth token is accepted (HTTP 200, not 403)
The "Enforce HTTPS checkbox becomes available" pattern from GitHub Pages applies here in spirit: do not consider a multi-artifact Firebase deploy "complete" until a real production request has succeeded through the full stack.
☐ Separate rules and functions into distinct deploy commands when both change
☐ Always deploy firestore:rules before functions in the same release
☐ Never use firebase deploy (all targets) for combined releases
☐ Add post-deploy functional test: one real request after functions deploy
☐ Monitor Firebase Functions logs for 403 errors in the 5 minutes after any deploy
☐ Document expected deploy order in release notes when both artifacts change
☐ Know that emulator passing does not validate deploy order correctness
This failure shares the infrastructure timing dependency pattern with:
Fix Confidence
Recovery Complexity
Pattern Family
This failure belongs to a named recurring pattern. Other failures in this family share the same root cause structure — understanding the pattern prevents multiple failure types simultaneously.
Related Failures in Same Pattern
Prevention Lessons
Completing these lessons would have prevented this failure.