fix(firebase-frameworks): don't delete an in-flight app on concurrent

[leoortizz]

Fixes #685

Problem

firebaseAppsLRU is keyed by uid and disposes with deleteApp. Two separate paths hand a request an app that is already being deleted.

Concurrent requests with the same __session cookie all miss the cache, so each one calls initializeApp and each set() deletes the app the previous request is still signing in with. The losers throw app/app-deleted, handleFactory does not catch, and Express answers 500.

A single request does it too, once the entry goes stale. A stale get() deletes the entry, which fires dispose and deleteApp, then returns that same app. deleteApp is async and nothing awaits it, and the rest of handleAuth is synchronous, so the request never notices. Teardown finishes while the page is awaiting, and the next use of res.locals.firebaseApp throws.

Fix

• Re-check the cache after the awaited revocation check, so only the first request initializes an app.
• Drop allowStale.
• Catch in handleFactory, so an auth failure degrades to an unauthenticated request instead of a 500.

Verification

Next.js 14.2 with the Firebase JS SDK, deployed to Hosting preview channels. Statuses come from the SSR function's own request log.

App Router, the reported scenario: eight <Link>s mount right after sign-in and prefetch at once against a cold entry.

firebase-frameworks	at the function
0.11.8	seven 500s with app/app-deleted, one 200
this branch	eight 200s

The 0.11.8 latencies match the table in the issue.

The stale path was checked on its own, with a page that awaits getIdToken() and then reads app.options. Once the entry is left idle past its 5 minute LRU_TTL, 0.11.8 serves the stale entry and the page fails with app/app-deleted, while this branch re-initializes and succeeds.

[gemini-code-assist]

Code Review

This pull request removes the allowStale option from the LRU cache, handles concurrent app initialization in handleAuth by checking the cache again after awaiting session cookie verification, and catches authentication errors in handleFactory to treat them as unauthenticated requests. The review feedback highlights a potential race condition and performance bottleneck with concurrent requests executing signInWithCustomToken simultaneously, suggesting caching the sign-in promise on the app instance to prevent redundant operations.

[Yuangwang]

LGTM