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

The error should be thrown in the case of the 403. I tried:

getToken(appCheck, { forceRefresh: true})
  .then((result) => console.log(result))
  .catch((e) => console.error("error", e));

The catch worked correctly and logged "error [the error message]" when I forced a 403 error by misspelling the projectId:

error FirebaseError: AppCheck: Requests throttled due to 403 error. Attempts allowed again after 01d:00m:00s (appCheck/throttled).

The recaptcha error (this one actually happens for me on the bad site key - did you get your examples reversed?) seems like it's going down the wrong code path. We added the internalError in the case that other products (Firestore, Auth, etc.) are trying to get the token by calling getToken internally - we don't want them to not get a possibly still-valid token just because there was an error trying to get a new one. That was done in this PR: #6617 - maybe we need to adjust the logic to ensure it still throws when a user calls getToken directly.

I think this can probably be fixed just by having the public-facing getToken() also throw on result.internalError here:

The error should be thrown in the case of the 403. I tried:

getToken(appCheck, { forceRefresh: true})
  .then((result) => console.log(result))
  .catch((e) => console.error("error", e));

The catch worked correctly and logged "error [the error message]" when I forced a 403 error by misspelling the projectId:

error FirebaseError: AppCheck: Requests throttled due to 403 error. Attempts allowed again after 01d:00m:00s (appCheck/throttled).

The recaptcha error (this one actually happens for me on the bad site key - did you get your examples reversed?) seems like it's going down the wrong code path. We added the internalError in the case that other products (Firestore, Auth, etc.) are trying to get the token by calling getToken internally - we don't want them to not get a possibly still-valid token just because there was an error trying to get a new one. That was done in this PR: #6617 - maybe we need to adjust the logic to ensure it still throws when a user calls getToken directly.

I think this can probably be fixed just by having the public-facing getToken() also throw on result.internalError here:

firebase-js-sdk/packages/app-check/src/api.ts

Line 210 in 51465ce

throw result.error;

Thank you, @hsubox76, for your response and for explaining the reasoning behind implementing internalError; that makes the intent clearer.

Regarding being able to catch the error correctly when misspelling the projectId, could you please try this while a valid cached token exists? The issue specifically occurs in this scenario—I should have made that clearer in the reproduction steps (I've now updated them). In this case, the error is silently suppressed instead of being surfaced.

While the cached token may still be valid, the purpose of forceRefresh: true is to fetch a new token, so returning the cached token in case of failure misleads the caller.

Regarding the error examples, I’ve double-checked and confirmed that they aren't reversed. However, in my examples, I misspelled the reCAPTCHA Enterprise site key from the Firebase console side. On the other hand, misspelling it in our codebase resulted in the following error:
FirebaseError: AppCheck: ReCAPTCHA error. (appCheck/recaptcha-error)

I agree with your suggested fix, and I’ve also opened a PR with an alternative approach. I’m happy to proceed with whichever direction you recommend as this issue is blocking us because our implementation requires a fresh token when forceRefresh: true is set, and without error propagation, we can't handle failures properly.

Looking forward to your thoughts! Thanks again.

We don't want to make this change in internal-api.ts because that code applies to both public calls of getToken() and internal calls, where we want too keep using a valid token, and not throw. Internal calls can also set forceRefresh=true. I've made a PR #8842 to change the public getToken() only, plus address some other considerations like distinguishing initial throttling errors (failed network response) from subsequent errors due to throttling (no network call made).