Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Error recovery: no retry path once an observable cache entry errors

Open
#742 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
firebase, react, typescript
Domain
frontend

Research direction

Start at preloadObservable and the global preloadedObservables cache, then trace SuspenseSubject error and reset behavior through the hook's non-suspense status path. Done means an agreed retry or reset path lets an errored entry recover with the same observableId, without requiring a different ID or remount workaround.

Written by the indexing model from the issue text.

Description

v5

Problem

Once a reactfire hook enters status: 'error', there is no way to recover without remounting with a different observableId.

The errored SuspenseSubject stays in the global preloadedObservables cache under its observableId. On error, the 30-second reset timer is cancelled (it becomes a no-op timeout), and the observable does not re-subscribe. A component that remounts with the same observableId rejoins the same errored subject and immediately receives status: 'error' again.

This became user-visible in v4.3.0, which made status: 'error' reachable in non-suspense mode (previously errors always threw, so the stuck state was hidden). Users building status === 'error' UI now have no way to trigger a retry.

Current workaround

Change the observableId passed to the hook. This causes preloadObservable to create a fresh SuspenseSubject and re-subscribe to the source. Not a real API — just an escape hatch.

What a fix might look like

  • An explicit retry() / reset() function returned from the hook, or
  • A retryOnError option that re-subscribes automatically after a delay, or
  • Cache eviction on error after the reset timeout (restoring the pre-v4.3 behavior for the cache entry, not for error surfacing)

The right shape is an open question. Filing to track the gap.

Closes none. Related to #735.

Dominant language
TypeScript
Stars
3.6k
Forks
403
Avg merge
4d 19h
Merged PRs (30d)
11

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FirebaseExtended/reactfire

All issues in FirebaseExtended/reactfire

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.