Skip to content

fix(auth): retry IndexedDB availability check on startup failure#9845

Draft
macastelaz wants to merge 2 commits intofirebase:mainfrom
macastelaz:fix-auth-indexeddb-availability
Draft

fix(auth): retry IndexedDB availability check on startup failure#9845
macastelaz wants to merge 2 commits intofirebase:mainfrom
macastelaz:fix-auth-indexeddb-availability

Conversation

@macastelaz
Copy link
Copy Markdown
Contributor

In environments like Chrome Extension Manifest V3 Service Workers, the initial IndexedDB transaction upon a cold start can sometimes drop or timeout. Previously, _isAvailable() would immediately catch the error, assume IndexedDB is broken, and silently fall back to inMemoryPersistence.

This updates _isAvailable() to use the _withRetries() helper, ensuring it benefits from the same retry logic as actual storage operations. This prevents the SDK from incorrectly abandoning existing IndexedDB auth state.

Fixes #9732

Hey there! So you want to contribute to a Firebase SDK?
Before you file this pull request, please read these guidelines:

Discussion

  • Read the contribution guidelines (CONTRIBUTING.md).
  • If this has been discussed in an issue, make sure to link to the issue here.
    If not, go file an issue about this before creating a pull request to discuss.

Testing

  • Make sure all existing tests in the repository pass after your change.
  • If you fixed a bug or added a feature, add a new test to cover your code.

API Changes

  • Changes that affect the public API will require internal review. Before making a
    PR that changes the public API, we would suggest first proposing your change in an
    issue so that we can discuss it together.

In environments like Chrome Extension Manifest V3 Service Workers, the initial IndexedDB transaction upon a cold start can sometimes drop or timeout. Previously, `_isAvailable()` would immediately catch the error, assume IndexedDB is broken, and silently fall back to `inMemoryPersistence`.

This updates `_isAvailable()` to use the `_withRetries()` helper, ensuring it benefits from the same retry logic as actual storage operations. This prevents the SDK from incorrectly abandoning existing IndexedDB auth state.

Fixes firebase#9732
@changeset-bot
Copy link
Copy Markdown

changeset-bot bot commented Apr 15, 2026

⚠️ No Changeset found

Latest commit: 960a789

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request implements retry logic for IndexedDB availability checks by utilizing the _withRetries helper within the _isAvailable method. It also includes new test cases to verify the retry behavior during database creation failures. Feedback was provided regarding a potential off-by-one error in the _withRetries loop condition, which currently requires an unintuitive call count assertion in the tests.

Comment on lines +107 to +109
expect((indexedDB.open as sinon.SinonStub).callCount).to.eq(
_TRANSACTION_RETRY_COUNT + 2
);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The expectation of _TRANSACTION_RETRY_COUNT + 2 (which evaluates to 5 attempts when the retry count is 3) indicates an off-by-one error in the underlying _withRetries helper's loop condition (numAttempts++ > _TRANSACTION_RETRY_COUNT). While _withRetries is not modified in this PR, this magic number in the test makes the logic less intuitive. Consider addressing the discrepancy in _withRetries by changing the condition to numAttempts++ >= _TRANSACTION_RETRY_COUNT so that the number of retries matches the constant's value, and then updating this test to expect _TRANSACTION_RETRY_COUNT + 1 total attempts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Auth state lost after service worker terminates despite successful sign-in

1 participant