Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Eleven wrapped callbacks and remote-config `isSupported` hold the app unstable until something that may never happen

Aberta
  • Algo errado?
#3,826 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 3 dias

@armando-navarro já está trabalhando nisso.

Desde 29/10/2026.

  • #3827 de @armando-navarro — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
angular, firebase, typescript
Domínio
api, backend, testing

Direção de pesquisa

Start with the ɵzoneWrap configuration and the generation rules in tools/build.ts, then compare the wrapped callbacks and remote-config isSupported with the existing onMessage and analytics or messaging entries. Check generated exports and tests for callback task handling and isSupported; done means the listed callbacks no longer block stability when their first event is not guaranteed, while callbacks still run in Angular context, and remote-config isSupported is generated with blockUntilFirst: false.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

comp: app-check comp: core comp: database comp: remote-config comp: ssr comp: zones type: bug version: current (v17+)
Version info

Angular: 22.2

Firebase: 12.19.0

AngularFire: 22.0.0-rc.0, and main

Description

ɵzoneWrap registers an Angular pending task as soon as a wrapped function is passed a callback, and releases it only when that callback first runs or the returned unsubscribe is called.

That is right for onValue, onSnapshotsInSync and onAuthStateChanged, which deliver a first value on attach. Eleven wrapped calls take a callback that a normal page load may never run, in which case ApplicationRef.isStable would stay false for good:

  • onLog from @angular/fire/app: never stable until some Firebase SDK logs, which a quiet app never does. It returns void, so no unsubscribe can release the task either.
  • onTokenChanged from @angular/fire/app-check: never stable until a token is obtained. With the setup docs/app-check.md shows (no isTokenAutoRefreshEnabled), a first visit that makes no protected request never obtains one.
  • onChildAdded from @angular/fire/database: never stable on an empty node. A new listener's initial events are only child_added, one per existing child, and value.
  • onChildChanged, onChildMoved, onChildRemoved from @angular/fire/database: never stable until someone changes, moves or removes a child. None of them fires on attach.
  • off(query, eventType, callback) from @angular/fire/database: never stable. It never calls the callback it is given and returns void.
  • enableLogging(fn) from @angular/fire/database: never stable until the database SDK logs something.
  • fromRef on a child event, and stateChanges and auditTrail with their default events, from @angular/fire/database: never stable on an empty node. They emit only on child events, so the task pendingUntilEvent registered is never released.

isSupported from @angular/fire/remote-config is a twelfth case with a different cause:

  • Its promise settles when an IndexedDB check answers, so a browser that never answers holds the app for good.
  • #3613 added isSupported: { blockUntilFirst: false } for it, matching the analytics and messaging copies, but in the rxfire/remote-config block of tools/build.ts, which exports no isSupported. The generator ignored the entry and remote-config shipped true.
  • #3759 deleted the dead entry and left the move for a follow-up.
How to reproduce these conditions

On a fresh Angular 22 app with @angular/fire@next, wrap each real function with ɵzoneWrap at true (the generated line), call it the way a constructor does, inside the Angular zone and an injection context, against the Database and Firestore emulators, and record every ApplicationRef.isStable emission:

  • onLog, onTokenChanged (provider with no token, no auto refresh), onChildAdded on an empty node, onChildChanged, onChildMoved and onChildRemoved on a node with three children: unstable from 0 ms, still unstable at 3 seconds, callback never ran. Same in a zone.js app and a zoneless one.
  • onChildAdded on a node with three children, onValue, onSnapshotsInSync, onTokenChanged with auto refresh on: unstable from 0 ms, stable again within 2 to 23 ms when the callback ran.
  • With false: no task registered, and inside the callback inject() still works and, under zone.js, NgZone.isInAngularZone() is still true.

A fresh Angular 22 SSR app that registers an onLog handler inside provideAppInitializer: with onLog imported from @angular/fire/app, ng build fails after about 30 seconds, the route extractor's timeout, with Routes extraction was aborted. TimeoutError: The operation was aborted due to timeout. With the identical file importing from firebase/app, it builds in about 2 seconds. That is the failure #3748 reported for beforeAuthStateChanged.

For isSupported: true holds the app unstable until the IndexedDB check answers, and for the whole window when indexedDB.open is stubbed to never fire. false registers no task. Inside the caller's .then, inject() throws and the zone is the one that attached the .then, at both values.

Expected behavior

A wrapped call whose first callback is not guaranteed by subscribing does not hold the application unstable, as onMessage, onRegistered, onUnregistered and beforeAuthStateChanged already do not. isSupported from @angular/fire/remote-config is wrapped like the analytics and messaging copies.

Actual behavior

All twelve are wrapped with blockUntilFirst true.

Linguagem predominante
TypeScript
Estrelas
7.8k
Forks
2.2k
Merge médio
2d 14h
PRs com merge (30d)
26

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de angular/angularfire

Todas as issues de angular/angularfire

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.