Not able to get any exceptions in iOS #1857

Sunsiha · 2022-07-06T19:17:54Z

I have created an application and uploaded to the TestFlight and Appstore also. First time user was able to login and then for next patch release I have uploaded to the TestFlight. Then am not able to signin only. Tried to catch the exception using toast/alert messages, firebase crashlytics. Then connected to the device which i have already installed the app from Testflight. And i run the application in real device tried to see console error, not able to see the exception again. Then i tried with fetchAuthSession didn't get any exception. Am getting only response for

final user = await Amplify.Auth.getCurrentUser();
print('user===${user.userId}');

I was able to get user id. But for all other cognito api's am not getting any exceptions or not even the response.

Software version 15.5
Model iPhone 12

Note:
The same code base is working for android device and simulator also.

The text was updated successfully, but these errors were encountered:

HuiSF · 2022-07-06T19:39:47Z

Hello @Sunsiha Thanks for reporting this issue.

Then am not able to signin only. Tried to catch the exception using toast/alert messages

Can you elaborate on this one a bit more?

How can you tell you were not able to sign in? Calling a specific auth API? 401'ed on API called etc.?
Which API call were you trying to catch possible exception with?

First time user was able to login and then for next patch release I have uploaded to the TestFlight.

sign out / re-sign in works as expected in the original version for everyone?
What's new in your patch release? (new logic? upgraded dependencies version?)

Sunsiha · 2022-07-06T19:52:31Z

Hello @HuiSF ,

How can you tell you were not able to sign in? Calling a specific auth API? 401'ed on API called etc.?

When I click on sign in button am calling the following API;

 SignInResult res = await Amplify.Auth.signIn(
          username: usernameController.text.trim(),
          password: passwordController.text.trim());

This am not getting any response or AmplifyException also.

Which API call were you trying to catch possible exception with?

signIn
fetchAuthSession

 AuthSession res = await Amplify.Auth.fetchAuthSession(
        options: CognitoSessionOptions(getAWSCredentials: true),
      );

sign out / re-sign in works as expected in the original version for everyone?

Signout also not throwing any error. In my code base it's like the same flow only.

What's new in your patch release? (new logic? upgraded dependencies version?)
Nothing with cognito. Tried to upgrading this amplify plugin version to 0.6.1 also. But it's not working.

HuiSF · 2022-07-06T20:04:14Z

This am not getting any response or AmplifyException also.

Do you mean await Amplify.Auth.signIn call never resolves? @Sunsiha

Do sign in and sign out still work in the old version?

Sunsiha · 2022-07-06T20:08:07Z

@HuiSF No it's not working. I tried. Such a weird issue.

Do sign in and sign out still work in the old version?
Nop. To check that only I updated the plugin. But for that also it didn't work.

HuiSF · 2022-07-06T20:18:52Z

Sorry the information you provided so far doesn't really help me to help you triaging this issue.

Please provide dependencies information following the command listed in this issue report template
I'm a bit confused with your versions. Can you confirm
1. Do sign in and sign out work in any version of your App? (Please be specific, e.g. 1.0.0 in App Store works, 1.0.1 patch version in TestFlight doesn't work)
2. If there is working version, what version of dependencies you are using for working version and not work version?
Review your patch version changes, if anything that prevents await Amplify.Auth.signIn from executing?
Review your Amplify App configuration? Have you changed auth category configuration? Have you change anything else that needed amplify push?
Have you tested you patch version in a develop environment? (e.g. in a simulator with debug build) were you able to reproduce this issue?

Sunsiha · 2022-07-06T20:26:41Z

Have uploaded first version like in 1.0.0 and tried to sign in first time it worked. Again with the same version not able to login. With 1.0.1 version also not working.
Have implemented new features related with the application. No changes related with cognito.
amplifyconfiguration.dart class i didn't do any changes.
As i mentioned it's working in simulator and Android device. No issues with the code base.

Sunsiha · 2022-07-06T20:47:54Z

@HuiSF May b chances are there with like this.

Scenario:

V.1.0.0 I have uploaded with QA environment userpool details. And I didn't log out or uninstall.
V.1.0.1 I have uploaded with stage environment userpool details. And downloaded from Testflight with update option. So when am trying to login I won't be able to catch any exceptions.

Note: After uninstall also the cognito user details may b not clearing.

HuiSF · 2022-07-06T21:13:01Z

Uninstall App won't clear credentials that are stored in device keychain. If the App bundle id remains the same, it looks up the existing credentials. This could be a cause.

But I need to confirm if anything can cause a silent exception in this scenario.

Can you try to clear the keychain in the testing device see if you can get around of this?

Sunsiha · 2022-07-06T21:17:57Z

Uninstall App won't clear credentials that are stored in device keychain. If the App bundle id remains the same, it looks up the existing credentials. This could be a cause.

But I need to confirm if anything can cause a silent exception in this scenario.

Can you try to clear the keychain in the testing device see if you can get around of this?

Actually I have changed the end points(Staging to QA) then it worked.

Can you try to clear the keychain in the testing device see if you can get around of this?

This I will again do one more upload with opposite like QA to Staging. Then will confirm you. Will clear the keychain also if i get the issue means.

But I feel this will be the cause. Just do confirm about a silent exception in this case.

Sunsiha · 2022-07-06T21:33:33Z

@HuiSF May b chances are there with like this.

Scenario:

V.1.0.0 I have uploaded with QA environment userpool details. And I didn't log out or uninstall.

V.1.0.1 I have uploaded with stage environment userpool details. And downloaded from Testflight with update option. So when am trying to login I won't be able to catch any exceptions.

Note: After uninstall also the cognito user details may b not clearing.

Yes this is the case.

HuiSF · 2022-07-06T23:03:56Z

I tested this scenario -

Setup an Amplify App with userpool 1
Signed up a user and signed in, left the user signed in and then uninstalled the App
Created userpool 2, swap out the configuration in the App
When call Amplify.Auth.signIn() below exception was raised

InvalidStateException(message: There is already a user which is signed in. Please log out the user before calling showSignIn., recoverySuggestion: Operation performed is not a valid operation for the current auth state, underlyingException: null)

It looks like this part is working correctly.

Sunsiha · 2022-07-07T03:36:12Z

I tested this scenario -

Setup an Amplify App with userpool 1

Signed up a user and signed in, left the user signed in and then uninstalled the App

Created userpool 2, swap out the configuration in the App

When call Amplify.Auth.signIn() below exception was raised
InvalidStateException(message: There is already a user which is signed in. Please log out the user before calling showSignIn., recoverySuggestion: Operation performed is not a valid operation for the current auth state, underlyingException: null)
It looks like this part is working correctly.

Yes. This I also used to get. But only when it is like TestFlight/appstore build am not getting any exception. And the scenario which I mentioned.

HuiSF · 2022-07-07T19:34:21Z

Hi @Sunsiha I tested again with release build today on a physical device.

Test 1:

Build App with userpool 1 config, install and sign in
Uninstall the App without signing out
Reinstall the App with the same userpool config 1 and attempt to sign in the same user, I received exception

InvalidStateException(message: There is already a user which is signed in. Please log out the user before calling showSignIn., recoverySuggestion: Operation performed is not a valid operation for the current auth state, underlyingException: null)

Test 2

Build App with userpool 1 config, install and sign in
Uninstall the App without signing out
Rebuild App with userpool 2 config, install and attempt sign in a user that exists in userpool 2
Sign in succeeded without There is already a user which is signed in exception (this is an expected behavior)

So everything seems working correctly from my testing.

The business logic should remain the same regardless build modes, or how to install the App. Could you double check the set up on your side?

Sunsiha · 2022-07-08T04:43:28Z

Hi @Sunsiha I tested again with release build today on a physical device.

Test 1:

Build App with userpool 1 config, install and sign in

Uninstall the App without signing out

Reinstall the App with the same userpool config 1 and attempt to sign in the same user, I received exception
InvalidStateException(message: There is already a user which is signed in. Please log out the user before calling showSignIn., recoverySuggestion: Operation performed is not a valid operation for the current auth state, underlyingException: null)
Test 2

Build App with userpool 1 config, install and sign in

Uninstall the App without signing out

Rebuild App with userpool 2 config, install and attempt sign in a user that exists in userpool 2

Sign in succeeded without There is already a user which is signed in exception (this is an expected behavior)

So everything seems working correctly from my testing.

The business logic should remain the same regardless build modes, or how to install the App. Could you double check the set up on your side?

This is happening when I install from TestFlight or Appstore.

Test 1:

Build App with userpool 1 config, upload it to Testflight , install and sign in.
Don't do signout or uninstall.
Build App with userpool 2 config, upload it to Testflight. Update it from TestFlight. Try to login(May be you can keep for alert for to catch exceptions).

And once we do this scenario when we try to do normal debug build I was not able to login. Unless I change to first userpool 1 config.

Sunsiha · 2022-07-24T13:49:15Z

@HuiSF am really not able to find why it is happening. Am getting only some user id when i try to call getuser() API. But when am trying to check that username in cognito userpool am not able to see that user id only. And in other device it's showing some other userid which is present in userpool also.

Jordan-Nelson · 2022-07-27T21:17:40Z

@Sunsiha - Can you please provide the info in the bug report template? I am particularly interested in what version of Amplify-flutter you are using, but having all the info from that template could help in reproducing this issue.

Can you also provide the contents of your ios/Podfile.lock file?

Sunsiha · 2022-08-03T17:15:02Z

@Jordan-Nelson #1998

Jordan-Nelson · 2022-08-05T13:37:38Z

Thanks @Sunsiha. Can you also share the contents of your ios/Podfile.lock? As I mentioned on the other issue, there was a known issue in Amplify-ios (which amplify-flutter depends on) where some data would not be cleared when the user pool was switched, causing an issue as you describe. I want to confirm which version of amplify-ios is being used in your project, which will be listed in your Podfile.lock.

Sunsiha · 2022-08-05T14:26:57Z

Thanks @Sunsiha. Can you also share the contents of your ios/Podfile.lock? As I mentioned on the other issue, there was a known issue in Amplify-ios (which amplify-flutter depends on) where some data would not be cleared when the user pool was switched, causing an issue as you describe. I want to confirm which version of amplify-ios is being used in your project, which will be listed in your Podfile.lock.

  - Amplify (1.25.0):
    - Amplify/Default (= 1.25.0)
  - Amplify/Default (1.25.0)
  - amplify_auth_cognito_ios (0.0.1):
    - Amplify (= 1.25.0)
    - amplify_core
    - AmplifyPlugins/AWSCognitoAuthPlugin (= 1.25.0)
    - Flutter
    - ObjectMapper
  - amplify_core (0.0.1):
    - Flutter
    - SwiftFormat/CLI
    - SwiftLint
  - amplify_flutter_ios (0.0.1):
    - Amplify (= 1.25.0)
    - amplify_core
    - AmplifyPlugins/AWSCognitoAuthPlugin (= 1.25.0)
    - AWSPluginsCore (= 1.25.0)
    - Flutter
    - SwiftFormat/CLI
    - SwiftLint
  - AmplifyPlugins/AWSCognitoAuthPlugin (1.25.0):
    - AWSAuthCore (~> 2.27.0)
    - AWSCognitoIdentityProvider (~> 2.27.0)
    - AWSCognitoIdentityProviderASF (~> 2.27.0)
    - AWSCore (~> 2.27.0)
    - AWSMobileClient (~> 2.27.0)
    - AWSPluginsCore (= 1.25.0)
  - AWSAuthCore (2.27.10):
    - AWSCore (= 2.27.10)
  - AWSCognitoIdentityProvider (2.27.10):
    - AWSCognitoIdentityProviderASF (= 2.27.10)
    - AWSCore (= 2.27.10)
  - AWSCognitoIdentityProviderASF (2.27.10):
    - AWSCore (= 2.27.10)
  - AWSCore (2.27.10)
  - AWSMobileClient (2.27.10):
    - AWSAuthCore (= 2.27.10)
    - AWSCognitoIdentityProvider (= 2.27.10)
    - AWSCognitoIdentityProviderASF (= 2.27.10)
    - AWSCore (= 2.27.10)
  - AWSPluginsCore (1.25.0):
    - Amplify (= 1.25.0)
    - AWSCore (~> 2.27.0)

DEPENDENCIES:
  - amplify_auth_cognito_ios (from `.symlinks/plugins/amplify_auth_cognito_ios/ios`)
  - amplify_core (from `.symlinks/plugins/amplify_core/ios`)
  - amplify_flutter_ios (from `.symlinks/plugins/amplify_flutter_ios/ios`)
  
SPEC REPOS:
  trunk:
    - Amplify
    - AmplifyPlugins
    - AWSAuthCore
    - AWSCognitoIdentityProvider
    - AWSCognitoIdentityProviderASF
    - AWSCore
    - AWSMobileClient
    - AWSPluginsCore

EXTERNAL SOURCES:
  amplify_auth_cognito_ios:
    :path: ".symlinks/plugins/amplify_auth_cognito_ios/ios"
  amplify_core:
    :path: ".symlinks/plugins/amplify_core/ios"
  amplify_flutter_ios:
    :path: ".symlinks/plugins/amplify_flutter_ios/ios"

SPEC CHECKSUMS:
  Amplify: 4e1839747f51c5f28f95ce36ef6d356f032b42b7
  amplify_auth_cognito_ios: 8a014f5d5e085265e13a270dc03fbe0818bb1f54
  amplify_core: e67fe0c53845db08aced670bfc7370b1329d2798
  amplify_flutter_ios: 59c43b6b6ff6ccfc59e18eef279d9d6b8fef8cca
  AmplifyPlugins: 110388250aeaf45eaf3008991616be84b2c605f7
 AWSAuthCore: ea9baff143a5ff4a98cea3954b006cedc96cd47e
  AWSCognitoIdentityProvider: 7ef13d7a86298db707165208f01b92997cc3b5af
  AWSCognitoIdentityProviderASF: d745c40a37815ef1c547f9677145d4e522f582f3
  AWSCore: dbad318b7ff0fd86fb8387d3ad1f30049c05bc58
  AWSMobileClient: 523cdb04d21cfd7523eb8db77b2fa2a00b6a95b4
  AWSPluginsCore: c29c4b91c4ecd7376b85288615bb482f409a0b73

Jordan-Nelson · 2022-08-05T17:02:33Z

@Sunsiha - Thank you for providing that.

The issue you are experiencing was fixed in AWSMobileClient (aka aws-sdk-ios) in v2.27.2 (see bug fixes in the release notes: https://github.com/aws-amplify/aws-sdk-ios/releases/tag/2.27.2). Amplify-flutter depends on amplify-ios, and amplify-ios depends on aws-sdk-ios.

Your project seems to have a direct dependency on v2.27.10 of AWSMobileClient ~~and a transitive dependency on v2.27.0. I think the version constraint in amplify-flutter and amplify-ios must not be forcing the latest version to be pulled in. I will look into this.~~

~~As a workaround - Can you try running pod update Amplify AWSPluginsCore AmplifyPlugins from the ios directory, and see if this updates all entries of AWSMobileClient to v2.27.2 or later?~~

With this fix, all credentials should be cleared on startup if the user pool changes.

Edit: See correction below. I will attempt to reproduce this issue with those versions.

Jordan-Nelson · 2022-08-05T17:15:49Z

Apologies for the confusion - I misread the output. The listing for the transitive dependency should not matter here. The actual dependency listing of v2.27.10 should be all that matters. That version should have the fix. I will attempt to reproduce that with those versions.

Jordan-Nelson · 2022-08-05T17:25:21Z

@Sunsiha - I would like to clarify one thing about the versions you are using to make sure that I am attempting to reproduce this with the exact versions you are using. In the other issue your dependencies included amplify_flutter v0.6.1. amplify_flutter v0.6.1 depends on amplify-ios v1.23.0. I can see from your podfile.lock though that you have a dependency on amplify-ios v1.25.0. The version was bumped in amplify_flutter v0.6.2 to 1.25.0. Can you confirm you are still depending on amplify_flutter 0.6.1? You can look for amplify_flutter in your .packages file to find the source and version.

You should see an entry like:

amplify_flutter:file:///Users/<username>/.pub-cache/hosted/pub.dartlang.org/amplify_flutter-0.6.1/lib/

Jordan-Nelson · 2022-08-05T18:21:56Z

Can you also confirm that you are able to reproduce this locally by making no other changes other than the user pool config? I know you mentioned versions uploaded to the App Store and Test Flight. I want to first confirm we can repro this locally since it will be harder to confirm the version in those versions. If we can first figure out how to repro this locally, we can then try to figure out what version those are using.

Jordan-Nelson · 2022-08-05T18:38:13Z

Can you also share your amplify config (with sensitive info removed)? This might be specific to certain sign up mechanism. So far I have been unable to repro this with username based sign in.

Sunsiha · 2022-08-05T18:46:47Z

amplify_flutter

amplify_flutter:file:///Users/sunishaguptan/tools/flutter/.pub-cache/hosted/pub.dartlang.org/amplify_flutter-0.6.4/lib/
amplify_flutter_android:file:///Users/sunishaguptan/tools/flutter/.pub-cache/hosted/pub.dartlang.org/amplify_flutter_android-0.6.4/lib/
amplify_flutter_ios:file:///Users/sunishaguptan/tools/flutter/.pub-cache/hosted/pub.dartlang.org/amplify_flutter_ios-0.6.4/lib/

Sunsiha · 2022-08-05T19:33:55Z

@Sunsiha - Do you know what version of Amplify-Flutter is used in the version deployed to the App Store and to the version(s) off the app on Test Flight?

Same what I mentioned. But in all these devices we used older version of amplify too. I mean they have installed the application with older version of amplify. Then when I started getting this kind of issue I updated with 0.6.1.

Like when I started the application for development i was using this version,

 amplify_flutter: ^0.2.10
 amplify_auth_cognito: ^0.2.10

then the release i done with

amplify_flutter: ^0.4.1
amplify_auth_cognito: ^0.4.1

Then when I got the issue I upgraded with

amplify_flutter: ^0.6.1
amplify_auth_cognito: ^0.6.1

But for testing we all used all these versions too.

Jordan-Nelson · 2022-08-05T20:31:35Z

The version of the app shipped with amplify-flutter 0.2.10 will not have the fix from the iOS SDK. The version using 0.4.1 likely does not have the fix from the iOS SDK either, although it is possible that it does. The version of the app you have locally does have the fix. I know this because the version of AWSMobileClient in your Podfile.lock is greater than 2.27.2.

Amplify-Flutter currently requires AWSMobileClient version 2.27.0 or higher (up to, but not including 2.28.0). If you have a version listed in your podfile.lock which meets that, it will be used. This unfortunately could include v2.27.0 or v2.27.1, which would not have the fix.

The version you have in your podfile.lock now is higher than 2.27.2 so you should not see this issue in subsequent builds (assuming this is committed to source control, which it should be). However, if you are testing with a build that doesn't have this fix, you will experience an issue when switching user pools.

I think it is likely that this issue is only surfacing for your team when they switch to a build that does not have the fix. To help prevent this you can log out prior to switch app versions (if you are switching user pools you will have to re-authenticate anyway). If this is being seen on a simulator, you can go to Device -> Erase all Content and Settings, which will clear the keychain for the device.

Sunsiha · 2022-08-07T17:14:23Z

The version of the app shipped with amplify-flutter 0.2.10 will not have the fix from the iOS SDK. The version using 0.4.1 likely does not have the fix from the iOS SDK either, although it is possible that it does. The version of the app you have locally does have the fix. I know this because the version of AWSMobileClient in your Podfile.lock is greater than 2.27.2.

Amplify-Flutter currently requires AWSMobileClient version 2.27.0 or higher (up to, but not including 2.28.0). If you have a version listed in your podfile.lock which meets that, it will be used. This unfortunately could include v2.27.0 or v2.27.1, which would not have the fix.

The version you have in your podfile.lock now is higher than 2.27.2 so you should not see this issue in subsequent builds (assuming this is committed to source control, which it should be). However, if you are testing with a build that doesn't have this fix, you will experience an issue when switching user pools.

I think it is likely that this issue is only surfacing for your team when they switch to a build that does not have the fix. To help prevent this you can log out prior to switch app versions (if you are switching user pools you will have to re-authenticate anyway). If this is being seen on a simulator, you can go to Device -> Erase all Content and Settings, which will clear the keychain for the device.

It's in real device. Any other solution i can do? Like we can clear keystore values or something before trying to login? since we can't go n tell each user to logout and all right?

Jordan-Nelson · 2022-08-07T21:30:33Z

@Sunsiha - have all the users that are experiencing this used the app with multiple user pools? If they have not used versions of the app with different user pools, than any issue they are experiencing would be something else.

Keychain will be cleared on app launch if the user pool has changed starting with v2.27.2. You could get the testers and/or users experiencing this a version of the app that as AWSMobileClient v2.27.2 or later. Since you have a later version in your Podfile.lock now, any future builds will have a version with the fix.

Sunsiha · 2022-08-08T03:41:57Z

@Sunsiha - have all the users that are experiencing this used the app with multiple user pools? If they have not used versions of the app with different user pools, than any issue they are experiencing would be something else.

Keychain will be cleared on app launch if the user pool has changed starting with v2.27.2. You could get the testers and/or users experiencing this a version of the app that as AWSMobileClient v2.27.2 or later. Since you have a later version in your Podfile.lock now, any future builds will have a version with the fix.

This app currently we are using internally. So in that one user facing the same issue. Since he never used any other user pool apart from prod. But he is not able to login. So only in my previous comments I said am not sure is it because of switching user pool.

With same user pool am using two applications. And both app the user installed and logged in before, Is there is any link because of that? Sorry @Jordan-Nelson Am also trying to understand the scenarios.

Jordan-Nelson · 2022-08-08T13:56:57Z

Data stored in Keychain is only accessible by an app with the same App ID (and developer team) as the app that created that data. So assuming the two apps have different App IDs, no - installing two different apps with two different user pools would not be an issue.

If you think there is any chance that this user installed a version of the app with a different user pool, you could have them install a newer version that will have this fix to see if that resolves it, but it sounds like this specific user may be facing a different issue.

Are you able to capture any logs from their session when they attempt to login?

Sunsiha · 2022-08-08T14:32:10Z

Not able to login in the app always when we change the user pool without logging out, when try to call getCurrentUser() userId is getting. #1998

Nop. I have two applications with same userpool app id's. Imagine we have A and B are the applications. A&B are using same user pool. Why two application means we are using both app for different purpose. Like one is client and another one is user.

But these things we doesn't have any issues in Android applications.

Sunsiha · 2022-08-08T17:38:25Z

@Jordan-Nelson I have uploaded new version again to the Appstore. Still for that user not able to login.

Jordan-Nelson · 2022-08-08T22:41:47Z

Do you have any logs from that user?

Jordan-Nelson · 2022-08-08T22:42:19Z

The issue for this user doesn't seem specific to switching user pools.

Sunsiha · 2022-08-09T08:31:31Z

Do you have any logs from that user?

Nope. Not getting logs as well.

Jordan-Nelson · 2022-08-09T23:17:13Z

Do you have any logs from that user?

Nope. Not getting logs as well.

Just to clarify, do you mean that you have not collected logs from that user, or do you mean that you have collected logs, and there is nothing in the logs when signIn is called?

If it is not working I would expect there to be an exception, which might give me a starting for trouble shooting.

Sunsiha · 2022-08-11T13:20:31Z

@Jordan-Nelson No logs am getting related with amplify. All are some background assertions.

Jordan-Nelson · 2022-08-11T22:22:02Z

Okay. How are you collecting logs?

Without reproducible steps or logs, this is going to be really difficult to determine the root cause. Is there anything specific about the device or OS this user is on? In the issue you had listed iPhone 12 and OS 15.5. Is that the device and OS this user is on?

Jordan-Nelson · 2022-08-19T16:25:17Z

@Sunsiha - Let me know what logs you are attempting to collect, and how you are collecting them. I would recommend adding some log statements in a catch clause of a try/catch around signIn. That way we can see if there are any exceptions coming from signIn.

It sounds like this is happening on a co-workers device. If you are able to debug this on the physical device, that would be ideal. But if not, you will need some way to collect the logs from their device.

Sunsiha · 2022-08-23T12:54:12Z

Okay. How are you collecting logs?

Without reproducible steps or logs, this is going to be really difficult to determine the root cause. Is there anything specific about the device or OS this user is on? In the issue you had listed iPhone 12 and OS 15.5. Is that the device and OS this user is on?

Actually this is one of my colleague device.
Details:

12.5.5 and iPhone 6

Sunsiha · 2022-08-23T12:55:55Z

@Sunsiha - Let me know what logs you are attempting to collect, and how you are collecting them. I would recommend adding some log statements in a catch clause of a try/catch around signIn. That way we can see if there are any exceptions coming from signIn.

It sounds like this is happening on a co-workers device. If you are able to debug this on the physical device, that would be ideal. But if not, you will need some way to collect the logs from their device.

Try catch have tried.. we are not able to get anything..such a weird .. I will check something and let you know.

getting this when am trying with simulator.

[AuthErrorHandler] The operation couldn’t be completed. (Amplify.AuthError error 7.)

Jordan-Nelson · 2022-08-26T01:58:06Z

Try catch have tried.. we are not able to get anything

Just to clarify, Amplify.Auth.SignIn() not completing OR throwing?

getting this when am trying with simulator

Are you experiencing this same issue on the simulator?

Sunsiha · 2022-08-26T06:41:48Z

Try catch have tried.. we are not able to get anything

Just to clarify, Amplify.Auth.SignIn() not completing OR throwing?

getting this when am trying with simulator

Are you experiencing this same issue on the simulator?

amplify api's not at all calling. It's not getting any exceptions in try catch also.

Am experiencing this same issue on the simulator.

Jordan-Nelson · 2022-08-26T11:50:38Z

Can you share the code you are using to sign a user in?

Are you still using Amplify version 0.6.1 and do you still have AWSMobileClient v2.27.10 in you Podfile.lock?

Sunsiha · 2022-08-26T14:20:21Z

Can you share the code you are using to sign a user in?

Are you still using Amplify version 0.6.1 and do you still have AWSMobileClient v2.27.10 in you Podfile.lock?

amplify_flutter: ^0.6.6
amplify_auth_cognito: ^0.6.6

podfile

PODS:
  - Amplify (1.28.0):
    - Amplify/Default (= 1.28.0)
  - Amplify/Default (1.28.0)
  - amplify_auth_cognito_ios (0.0.1):
    - Amplify (= 1.28.0)
    - amplify_core
    - AmplifyPlugins/AWSCognitoAuthPlugin (= 1.28.0)
    - Flutter
    - ObjectMapper
  - amplify_core (0.0.1):
    - Flutter
    - SwiftFormat/CLI
    - SwiftLint
  - amplify_flutter_ios (0.0.1):
    - Amplify (= 1.28.0)
    - amplify_core
    - AmplifyPlugins/AWSCognitoAuthPlugin (= 1.28.0)
    - AWSPluginsCore (= 1.28.0)
    - Flutter
    - SwiftFormat/CLI
    - SwiftLint
  - AmplifyPlugins/AWSCognitoAuthPlugin (1.28.0):
    - AWSAuthCore (~> 2.27.0)
    - AWSCognitoIdentityProvider (~> 2.27.0)
    - AWSCognitoIdentityProviderASF (~> 2.27.0)
    - AWSCore (~> 2.27.0)
    - AWSMobileClient (~> 2.27.0)
    - AWSPluginsCore (= 1.28.0)
  - AWSAuthCore (2.27.13):
    - AWSCore (= 2.27.13)
  - AWSCognitoIdentityProvider (2.27.13):
    - AWSCognitoIdentityProviderASF (= 2.27.13)
    - AWSCore (= 2.27.13)
  - AWSCognitoIdentityProviderASF (2.27.13):
    - AWSCore (= 2.27.13)
  - AWSCore (2.27.13)
  - AWSMobileClient (2.27.13):
    - AWSAuthCore (= 2.27.13)
    - AWSCognitoIdentityProvider (= 2.27.13)
    - AWSCognitoIdentityProviderASF (= 2.27.13)
    - AWSCore (= 2.27.13)
  - AWSPluginsCore (1.28.0):
    - Amplify (= 1.28.0)
    - AWSCore (~> 2.27.0)

Sign in code

  void _signIn() async {
    FocusScope.of(context).requestFocus(FocusNode());
    loaderVisibility(true);
    await CognitoRepo()
        .cognitoSignOut()
        .then((response) {})
        .catchError((onError) => print(onError));
    try {
      try {
        SignInResult res = await Amplify.Auth.signIn(
            username: usernameController.text.trim(),
            password: passwordController.text.trim());
        if (res.isSignedIn == true) {
         
        }
      } on Exception catch (e) {
        // TODO
        print('exception==$e');
      }
    } on AmplifyException catch (e) {
      setState(() {
        _loaderVisibility = false;
      });
    }
  }

CognitoRepo

class CognitoRepo {
  Future cognitoSignOut() async {
    // SignOutResult res = await Amplify.Auth.signOut();
    SignOutResult res = await Amplify.Auth.signOut(
        options: const SignOutOptions(globalSignOut: true));
    return res;
  }
}

Jordan-Nelson · 2022-09-19T20:22:10Z

@Sunsiha - Apologies for the delay as I missed your last response.

Can you run the app on the simulator from Xcode and view the logs during sign in? Logs from the amplify-ios SDK will not show in the flutter console output.

Jordan-Nelson · 2022-11-09T21:02:36Z

@Sunsiha - Have you have a chance to run this from Xcode to view the logs?

HuiSF · 2022-12-02T22:38:00Z

Hi @Sunsiha sorry we didn't hear back from you! Please feel free to reopen and follow up if you need further assistance.

SolomiyaN · 2023-02-27T22:52:49Z

Hey,

I think I have a similar issue here. I am trying to integrate Amplify authorisation into my native iOS app. Two-step sign up works well, which points that the configuration should be fine.

But I am facing some buggy behaviour during the sign in as well as @Sunsiha did. The try await doesn't resolve at all. I catch no errors, no anything.

I have added Amplify 2.4.0 though Xcode packages and did this:

        do {
            let options = AWSAuthSignInOptions(authFlowType: .userPassword)
            let signInResult = try await Amplify.Auth.signIn(
                username: username,
                password: password,
                options: .init(pluginOptions: options)
                )
            if signInResult.isSignedIn {
                print("Sign in succeeded")
            } else {
                print("Something is wrong")
            }
        } catch let error as AuthError {
            print("Sign in failed \(error)")
        } catch {
            print("Unexpected error: \(error)")
        }

Is there something I am missing here?

dnys1 · 2023-02-27T23:23:48Z

Hi @SolomiyaN, sorry you are facing this issue. For questions related to Amplify Swift, can you fill out a ticket in the https://github.com/aws-amplify/amplify-swift repo? They should be able to better assist you over there.

HuiSF added auth Issues related to the Auth Category pending-response Issue is pending response from the issue requestor pending-triage This issue is in the backlog of issues to triage labels Jul 6, 2022

HuiSF added the not-reproducible Issues that cannot be reproduced using the steps provided label Jul 7, 2022

Jordan-Nelson self-assigned this Jul 27, 2022

Jordan-Nelson mentioned this issue Aug 8, 2022

Not able to login in the app always when we change the user pool without logging out, when try to call getCurrentUser() userId is getting. #1998

Closed

13 tasks

Jordan-Nelson added pending-close-response-required The issue will be closed if details necessary to reproduce the issue are not provided within 7 days. and removed pending-response Issue is pending response from the issue requestor labels Nov 9, 2022

HuiSF closed this as not planned Won't fix, can't repro, duplicate, stale Dec 2, 2022

Not able to get any exceptions in iOS #1857

Not able to get any exceptions in iOS #1857

Comments

Sunsiha commented Jul 6, 2022 • edited

HuiSF commented Jul 6, 2022

Sunsiha commented Jul 6, 2022

HuiSF commented Jul 6, 2022

Sunsiha commented Jul 6, 2022 • edited

HuiSF commented Jul 6, 2022

Sunsiha commented Jul 6, 2022

Sunsiha commented Jul 6, 2022 • edited

HuiSF commented Jul 6, 2022

Sunsiha commented Jul 6, 2022

Sunsiha commented Jul 6, 2022

HuiSF commented Jul 6, 2022

Sunsiha commented Jul 7, 2022

HuiSF commented Jul 7, 2022 • edited

Sunsiha commented Jul 8, 2022 • edited

Sunsiha commented Jul 24, 2022 • edited

Jordan-Nelson commented Jul 27, 2022

Sunsiha commented Aug 3, 2022

Jordan-Nelson commented Aug 5, 2022

Sunsiha commented Aug 5, 2022

Jordan-Nelson commented Aug 5, 2022 • edited

Jordan-Nelson commented Aug 5, 2022

Jordan-Nelson commented Aug 5, 2022

Jordan-Nelson commented Aug 5, 2022

Jordan-Nelson commented Aug 5, 2022

Sunsiha commented Aug 5, 2022

Sunsiha commented Aug 5, 2022 • edited

Jordan-Nelson commented Aug 5, 2022

Sunsiha commented Aug 7, 2022 • edited

Jordan-Nelson commented Aug 7, 2022

Sunsiha commented Aug 8, 2022

Jordan-Nelson commented Aug 8, 2022

Sunsiha commented Aug 8, 2022

Sunsiha commented Aug 8, 2022

Jordan-Nelson commented Aug 8, 2022

Jordan-Nelson commented Aug 8, 2022

Sunsiha commented Aug 9, 2022

Jordan-Nelson commented Aug 9, 2022

Sunsiha commented Aug 11, 2022

Jordan-Nelson commented Aug 11, 2022

Jordan-Nelson commented Aug 19, 2022

Sunsiha commented Aug 23, 2022

Actually this is one of my colleague device. Details:

Sunsiha commented Aug 23, 2022 • edited

Jordan-Nelson commented Aug 26, 2022 • edited

Sunsiha commented Aug 26, 2022

Jordan-Nelson commented Aug 26, 2022

Sunsiha commented Aug 26, 2022

podfile

CognitoRepo

Jordan-Nelson commented Sep 19, 2022

Jordan-Nelson commented Nov 9, 2022

HuiSF commented Dec 2, 2022

SolomiyaN commented Feb 27, 2023

dnys1 commented Feb 27, 2023

Sunsiha commented Jul 6, 2022 •

edited

Sunsiha commented Jul 6, 2022 •

edited

Sunsiha commented Jul 6, 2022 •

edited

HuiSF commented Jul 7, 2022 •

edited

Sunsiha commented Jul 8, 2022 •

edited

Sunsiha commented Jul 24, 2022 •

edited

Jordan-Nelson commented Aug 5, 2022 •

edited

Sunsiha commented Aug 5, 2022 •

edited

Sunsiha commented Aug 7, 2022 •

edited

Actually this is one of my colleague device.
Details:

Sunsiha commented Aug 23, 2022 •

edited

Jordan-Nelson commented Aug 26, 2022 •

edited