Redundant token exchange requests when using App Check debug token with concurrent getToken() calls

[nicole0707]

Operating System

macOS Sequoia

Environment (if applicable)

Chrome 138, Node 20.19.2, Next.js 14

Firebase SDK Version

12.0.0

Firebase SDK Product(s)

AppCheck

Project Tooling

Next.js with firebase/app-check

Detailed Problem Description

We’ve observed that when using App Check in debug mode https://github.com/firebase/firebase-js-sdk/blob/main/packages/app-check/src/internal-api.ts#L122-L130, concurrent calls to getToken() (e.g. during page initialization from multiple components) often result in multiple token exchange requests, rather than sharing a single in-flight promise.

In our case, we call getToken() in several places on page load, and even though the first call is still pending, subsequent calls don’t appear to reuse the in-progress request.

We’ve worked around this by implementing our own cached promise wrapper, but ideally, this should be handled inside the SDK, especially in debug mode, where duplicate requests may trigger rate-limiting or test pollution.

Steps and code to reproduce issue

// Assume App Check has already been initialized in debug mode
// and FIREBASE_APPCHECK_DEBUG_TOKEN is set
// Simulate concurrent calls from different parts of the app
Promise.all([
  getToken(appCheck),  // Call 1
  getToken(appCheck),  // Call 2
  getToken(appCheck)   // Call 3
]).then(() => {
  console.log("All token calls completed");
});

In this setup, we expect all three calls to share the same in-flight promise and result in only one network request to the debug token exchange endpoint. However, this triggers three separate exchange requests, which can be seen in the network panel or logs.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[hsubox76]

So I stepped through the code and it looks like this is just a consequence of how JS concurrency works.

// A  if (!state.exchangeTokenPromise) {
// B    state.exchangeTokenPromise = exchangeToken(
          getExchangeDebugTokenRequest(app, await getDebugToken()),
          appCheck.heartbeatServiceProvider
        ).finally(() => {
          // Clear promise when settled - either resolved or rejected.
          state.exchangeTokenPromise = undefined;
        });
        shouldCallListeners = true;
      }

I labeled the important lines A and B.

So in the case of your example (3 parallel calls to getToken) the condition in line A (if (!state.exchangeTokenPromise)) executes 3 times before any of the calls even moves on to line B, and it will of course be true for each of the 3 parallel tasks, so they will move onto line B, which makes the network call.

In order for the detection of an in-flight promise to block calls 2 and 3, it would require line B of call 1 to execute (assigning something to state.exchangeTokenPromise and making the previous condition false) before calls 2 and 3 reach line A, and I guess concurrency just means each task takes turns going line by line. I'm not really sure how to get around this? I might just be missing something obvious, let me know if you think of anything, I'll keep thinking about it also.

[nicole0707]

@hsubox76 Thank you for stepping in and clearly walking through the issue with the concurrency between lines A and B , that breakdown helped validate the core problem.

You're absolutely right: all parallel getToken() calls were evaluating !state.exchangeTokenPromise before any of them had a chance to set it, which caused multiple redundant exchangeToken() requests.

To resolve this, we can update the logic so that getDebugToken() is awaited before we check the promise state, and we immediately assign state.exchangeTokenPromise once the network request is kicked off. This guarantees that only one call proceeds to make the request, and all other concurrent calls await the same shared promise.

It’s worth noting that getDebugToken() is lightweight, it simply resolves a value from global state https://github.com/firebase/firebase-js-sdk/blob/main/packages/app-check/src/debug.ts#L65-L69 and does not perform any network I/O. So moving it outside the condition does not introduce any performance penalty or new race window.

Can you have a look my PR if it makes sense?