Hi Nicolas,
Thank you for taking the time to look at this. I started from scratch and indeed couldn’t reproduce the problem. Trying to compare this code against the app where I had with the failure, it looks like the problem came down to getTokenSilently({}) not doing the same thing as getTokenSilently(). I suspect at some point when I was trying to make the audience work, I just deleted the property rather than the entire arg, thinking the argument would be merged with the defaults.
I’m a little uneasy attributing all the problems I’ve been having entirely to that because I didn’t start trying to specify an audience (and thus, pass an argument at all) in the getTokenSilently call until after I was already having problems getting the token. But, the table of error states I presented previously appears to only hold true when passing an empty object as the argument to getTokenSilently. As for the original problem, maybe webpack did something unexpected, a stale build stuck around, or an older version of auth0-spa-js had an issue. I really don’t know, but I’m having difficulties reproducing the initial error to verify, since I’ve blown away node_modules, upgraded auth0-spa-js, and made myriad other changes while trying to track down the problem.
In any event, I’m happy to have it working now. And thank you very much for taking the time to help me work it out. I think there may still be some opportunities to improve either the aesthetics or the error messages around this call. I’m happy to attribute a getTokenSilently({}) call to user error, but picking a completely different audience ("default") in that case and resulting in errors far removed from the source of the issue isn’t ideal. I appreciate you can’t protect users from all the horrible things they may do. Perhaps argument validation or merging the argument with the provider’s values would be a worthwhile compromise.