Amplify-js: Unhandled Promise rejection when adding in <amplify-authenticator></amplify-authenticator>

[etjenkins]

Describe the bug
When adding the component into the HTML for an Angular App, on the page load it results in:
zone-evergreen.js:659 Unhandled Promise rejection: not authenticated ; Zone: <root> ; Task: Promise.then ; Value: not authenticated undefined
Chrome, Firefox, Safari (OSX) and Edge (new version) can handle this and carry on so you are still able to log in, but on Edge (legacy version) and Safari on mobile it prevents the login UI loading making the application useless.

If the HTML component is not there this error does not occur

To Reproduce
Simplest reproduction, follow this tutorial - https://docs.amplify.aws/ui/auth/authenticator/q/framework/angular
Add the following into polyfill.ts
(window as any).global = window; (window as any).process = { env: { DEBUG: undefined }, };
Note you will need to create the aws-exports.js file

Then do ng serve and open the console and there is the error. In Chrome you would still be able to login but IE / Legacy Edge the UI does not even load.

See Stackblitz for example app with minimal setup.
https://stackblitz.com/edit/angular-ivy-mkqpwz

Expected behavior
There should not be a promise rejection, or it should be handled correctly so it does not stop the login components from working.

Code Snippet
https://stackblitz.com/edit/angular-ivy-mkqpwz

What is Configured?
Angular project using Angular 10, following package.json
"dependencies": { "@angular/animations": "~9.0.6", "@angular/common": "~9.0.6", "@angular/compiler": "~9.0.6", "@angular/core": "~9.0.6", "@angular/forms": "~9.0.6", "@angular/platform-browser": "~9.0.6", "@angular/platform-browser-dynamic": "~9.0.6", "@angular/router": "~9.0.6", "@aws-amplify/ui-angular": "^0.2.14", "aws-amplify": "^3.0.23", "rxjs": "~6.5.4", "tslib": "^1.10.0", "zone.js": "~0.10.2" }, "devDependencies": { "@angular-devkit/build-angular": "~0.900.6", "@angular/cli": "~9.0.6", "@angular/compiler-cli": "~9.0.6", "@angular/language-service": "~9.0.6", "@types/node": "^12.11.1", "@types/jasmine": "~3.5.0", "@types/jasminewd2": "~2.0.3", "codelyzer": "^5.1.2", "jasmine-core": "~3.5.0", "jasmine-spec-reporter": "~4.2.1", "karma": "~4.3.0", "karma-chrome-launcher": "~3.1.0", "karma-coverage-istanbul-reporter": "~2.1.0", "karma-jasmine": "~2.0.1", "karma-jasmine-html-reporter": "^1.4.2", "protractor": "~5.4.3", "ts-node": "~8.3.0", "tslint": "~5.18.0", "typescript": "~3.7.5" }
Everything was configured by the Amplify CLI, for a minimal setup these steps can be skipped as the issue is loading the HTML component that triggers the error.

Desktop:

• OS: Windows 10, OSX
• Browser: Latest versions of Chrome, Firefox, Safari, Edge and legacy Edge

Any help would be greatly appreciated 👍

[WolfWalter]

I had the same issue. I guess the issue is related of a mixture of es5 and esm Files. The esm Version of amplify-authenticator.entry.js (ui-components) was used, while the Auth.js file from the lib-esm folder was used, but it looks like it was transpiled to es5? I tired to debug this and the throw 'not authenticated'; in the Auth.js was not catched by the catch statement:

  async checkUser() {
        if (!Auth || typeof Auth.currentAuthenticatedUser !== 'function') {
            throw new Error(NO_AUTH_MODULE_FOUND);
        }
        try {
            const user = await Auth.currentAuthenticatedUser();
            dispatchAuthStateChangeEvent(AuthState.SignedIn, user);
        }
        catch (error) {
...

When setting the the target in tsconfig.app.json to es5 the issue no longer occurs:

...
"compilerOptions": {
  "target": "es5",
  ...
}

[etjenkins]

Thanks for the solution, it does resolve it, however do we want to be targeting es5 when es11/2020 has been released. I know we can use polyfills but does this still not to be fixed properly in Amplify so it does work with the latest versions? Or is this more of an Angular compilation issue? I am still fairly new to working with the different ES versions and how they work.

[mattAtPropertyMe]

Confirmed targeting es5 removes the Unhandled Promise rejection error, thanks @WolfWalter

Agreed @etjenkins, at a minimum we should be able to target es2015/es6.

It also seems the recent change/re-launch from v2 to v3 for the Amplify JavaScript libs was supposed to introduce 'Modularized Amplify libraries', which enable tree shaking. However I can't see how this is 100% achievable, given it's continued dependence on CommonJS modules...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Rajan-Gupta1]

@sammartinez @ashika01 I am still getting the exception, can it be confirmed:

1. Is the exception the expected behavior and can be okay
2. Is there a fix planned?
3. Or the user of amplify-js has to do something about it and if so what ?

[stale[bot]]

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.

[EvanSchalton]

bump, still outstanding

[sammartinez]

@EvanSchalton Apologies that issue got closed! I will see if my oncall can take a look at this.

[wlee221]

Hi! Sorry about the delayed response, and thanks @etjenkins for details. I was able to reproduce this issue with latest Amplify and am investigating this issue. What I found so far:

• When amplify-authenticator renders, the component calls Auth.currentAuthenticatedUser in line 97 to see if a user has logged in.
• Because no user has logged in yet, Auth.currentAuthenticatedUser throws a not authenticated error in line 1284.
• This error should be handled by the try...catch block in lines 96-114. The app then enters the catch block as expected... but the promise is still considered unhandled.

This doesn't happen in React / Vue, so I'm suspecting that this is related to how zone.js (used by angular cli) handles unhandled promises. We'll investigate further and keep you all updated. If anyone has an idea what the root cause is, please feel free to contribute!

[wlee221]

@sammartinez @ashika01 I am still getting the exception, can it be confirmed:

1. Is the exception the expected behavior and can be okay

This exception shouldn't impact amplify-authenticator usage or inflict any security concerns, as this exception is just checking that no user has authenticated yet.

[EvanSchalton]

I just want to say -- I really appreciate how responsive you guys have been to this, thank you 👍

[wlee221]

Hi all, this should be fixed in #7121. I will let you know when this gets published to the latest. Meanwhile, It will be available in "aws-amplify": unstable shortly to try it out!

[wlee221]

Forgot to mention: This is out in the latest! Please let us know if the issue persists.