amplify-flutter
amplify-flutter copied to clipboard
Support "unidentify" in Analytics.identifyUser
Description
I've been testing my app (removing and reinstalling) on a simulator. After a while I got this exception on Amplify.Analytics.identifyUser()
:
UnknownException (UnknownException {
"message": "Error in request data sent to Pinpoint.",
"recoverySuggestion": "An unknown exception has happened. Please take a look at \n https://github.com/aws-amplify/amplify-flutter/issues to see if there are any existing issues that \n match your scenario, and file an issue with the details of the bug if there isn't.\n ",
"underlyingException": "BadRequestException {\n message=Exceeded maximum endpoint per user count:15,\n}"
})
I think that this will cause issues with push notifications and any events recording
I know that there's a maximum of endpoints per user but this issue appeared after I deleted the app from the simulator and reinstalled it. Should this be considered the same endpoint?
Thank you!
Categories
- [X] Analytics
- [ ] API (REST)
- [ ] API (GraphQL)
- [ ] Auth
- [ ] Authenticator
- [ ] DataStore
- [ ] Notifications (Push)
- [ ] Storage
Steps to Reproduce
- Run an app and identifyUser
- Remove and reinstall the app on the same simulator 15 times.
Screenshots
No response
Platforms
- [X] iOS
- [X] Android
- [ ] Web
- [ ] macOS
- [ ] Windows
- [ ] Linux
Flutter Version
3.10.6
Amplify Flutter Version
1.3.1
Deployment Method
Amplify CLI
Schema
No response
Hi @jamilsaadeh97 thanks for sharing this issue. This is a known limitation of 15 endpoints per user id. The underlying Pinpoint service needs to update their functionality regarding this limit.
Specifically for your case, the problem is that AWS Pinpoint has been associating the same endpoint to the same user id. So each time you uninstalled and reinstalled the device, and logged in with that same user, a new endpoint was being associated to that user.
Given what you explained, this should be an extreme edge case that only occurs during testing. Would creating a new user and testing with that work for you?
Hi @fjnoyp , yes creating a new user works.
I think for long term applications, this will cause issues since an application can be installed and uninstalled on the same device multiple times in the long run. Is there a way to clear the devices/endpoints for a specific application?
Thank you!
Hi @jamilsaadeh97 - Agreed that this is an issue that we have been escalating to the Pinpoint team to get a solution from the service itself. In terms of clearing the device/endpoints, unfortunately, the only way to do that is by using the Pinpoint APIs, and retrieve the endpoints that you want to delete as an Admin user.
Hi @abdallahshaban557 thank you for the info!
I saw your comment on how to "unidentify" a user when signing out, to stop receiving notifications, by passing an empty string as the user id. Will this empty user id be associated with the endpoint or will it just be discarded by Pinpoint? If yes, then I think the issue of 15 max endpoints will also rise if different users sign out (all of them will have a user id of "")
Hi @jamilsaadeh97 - that is a great point. I will check with the team and get back to you.
Thank you @abdallahshaban557 , waiting for your answer!
Hi @jamilsaadeh97 - you should pass null rather than an empty string so that you do not run into that issue. I am updating my previous answer now as well.
Hi @abdallahshaban557, the identifyUser function of Analytics and Notifications doesn't accept null as parameter for the userId (nor for the UserProfile):
Future<void> identifyUser({required String userId, required UserProfile userProfile})
I am checking with the team now!
Hi @jamilsaadeh97 we will look into updating the identifyUser
API to allow for nullable types to allow for Pinpoint users to be unidentified. Thanks for sharing the details of your issue here!
Hi @fjnoyp , thank you for this. Do you think that it's gonna be a fast fix or it might be more complex?
Hi @jamilsaadeh97 we're taking a look. There might be a problem with the underlying Pinpoint API that we're investigating here - sending a "" for userId is not causing user to be "unidentified" at the moment.