Pinpoint: Exceeded maximum endpoint per user count: 15

[joebernard]

Describe the bug
After upgrading to "@aws-amplify/analytics": "^4.0.0" push notifications have stopped working. I can no longer update endpoints. This was originally solved in #5423 but seems to have reappeared recently. Possibly related to the merge in #7245 .

To Reproduce
Install the app on a device more than 10 times.

Expected behavior
Amplify should clear old endpoints as mentioned in the docs.

Environment

System:
    OS: macOS 10.15.7
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
    Memory: 208.17 MB / 32.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 14.2.0 - ~/.nvm/versions/node/v14.2.0/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 6.14.8 - ~/.nvm/versions/node/v14.2.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Browsers:
    Chrome: 86.0.4240.198
    Firefox: 82.0.3
    Safari: 14.0
  npmPackages:
    @apollo/client: ^3.2.7 => 3.2.7 
    @aws-amplify/analytics: ^4.0.0 => 4.0.0 
    @aws-amplify/auth: ^3.4.12 => 3.4.12 
    @aws-amplify/cache: ^3.1.37 => 3.1.37 
    @aws-amplify/core: ^3.8.4 => 3.8.4 
    @aws-amplify/storage: ^3.3.12 => 3.3.12 
    @babel/core: ^7.8.4 => 7.11.6 
    @babel/runtime: ^7.8.4 => 7.9.2 
    @bugsnag/react-native: ^7.5.2 => 7.5.2 
    @expo/react-native-action-sheet: ^3.8.0 => 3.8.0 
    @react-native-community/art: ^1.2.0 => 1.2.0 
    @react-native-community/async-storage: ^1.12.1 => 1.12.1 
    @react-native-community/eslint-config: ^1.1.0 => 1.1.0 
    @react-native-community/masked-view: ^0.1.10 => 0.1.10 
    @react-native-community/netinfo: ^5.9.7 => 5.9.7 
    @react-native-community/picker: ^1.8.1 => 1.8.1 
    @react-native-community/push-notification-ios: 1.7.3 => 1.7.3 
    @types/react: 16.9.56 => 16.9.56 
    amazon-cognito-identity-js: ^4.5.5 => 4.5.5 
    apollo-link-retry: ^2.2.16 => 2.2.16 
    appcenter: 3.1.2 => 3.1.2 
    appcenter-analytics: 3.1.2 => 3.1.2 
    appcenter-crashes: 3.1.2 => 3.1.2 
    aws-appsync-auth-link: ^3.0.2 => 3.0.2 
    aws-appsync-subscription-link: ^3.0.3 => 3.0.3 
    babel-jest: ^25.1.0 => 25.5.1 
    eslint: ^6.5.1 => 6.8.0 
    exponential-backoff: ^3.1.0 => 3.1.0 
    graphql: 15.4.0 => 15.4.0 
    jest: ^25.1.0 => 25.5.4 
    lodash.debounce: ^4.0.8 => 4.0.8 
    lodash.throttle: ^4.1.1 => 4.1.1 
    metro-react-native-babel-preset: ^0.59.0 => 0.59.0 
    moment: ^2.29.1 => 2.29.1 
    moment-timezone: ^0.5.32 => 0.5.32 
    prop-types: ^15.7.2 => 15.7.2 
    react: 16.13.1 => 16.13.1 
    react-dom: ^16.12.0 => 16.13.1 
    react-native: 0.63.3 => 0.63.3 
    react-native-animatable: ^1.3.3 => 1.3.3 
    react-native-camera: 3.40.0 => 3.40.0 
    react-native-code-push: ^6.4.0 => 6.4.0 
    react-native-config: 1.4.0 => 1.4.0 
    react-native-country-picker-modal: ^2.0.0 => 2.0.0 
    react-native-device-info: ^7.1.0 => 7.1.0 
    react-native-fast-image: ^8.3.4 => 8.3.4 
    react-native-fs: ^2.16.6 => 2.16.6 
    react-native-gesture-handler: ^1.8.0 => 1.8.0 
    react-native-get-random-values: ^1.5.0 => 1.5.0 
    react-native-haptic-feedback: ^1.11.0 => 1.11.0 
    react-native-orientation-locker: ^1.2.0 => 1.2.0 
    react-native-permissions: ^2.2.2 => 2.2.2 
    react-native-progress: ^4.1.2 => 4.1.2 
    react-native-reanimated: ^1.13.2 => 1.13.2 
    react-native-root-toast: ^3.2.1 => 3.2.1 
    react-native-safe-area-context: ^3.1.9 => 3.1.9 
    react-native-safe-area-view: ^2.0.0 => 2.0.0 
    react-native-screens: ^2.15.0 => 2.15.0 
    react-native-share: 4.1.0 => 4.1.0 
    react-native-svg: ^12.1.0 => 12.1.0 => 0.3.4 
    react-native-tab-view: ^2.15.2 => 2.15.2 
    react-native-vector-icons: 7.1.0 => 7.1.0 
    react-native-video: ^5.1.0-alpha8 => 5.1.0-alpha8 
    react-native-webview: ^10.10.2 => 10.10.2 
    react-navigation: ^4.4.3 => 4.4.3 
    react-navigation-props-mapper: ^1.0.0 => 1.0.4 
    react-navigation-stack: ^2.10.1 => 2.10.1 
    react-navigation-tabs: ^2.10.1 => 2.10.1 
    react-test-renderer: 16.13.1 => 16.13.1 
    uuid: ^8.3.1 => 8.3.1 
  npmGlobalPackages:
    @aws-amplify/cli: 4.32.1
    appcenter-cli: 2.7.2
    gatsby-cli: 2.14.0
    lerna: 3.22.1
    npm: 6.14.8
    serverless: 2.11.1
    typescript: 3.9.6

Additional context
May be related to #7245

[jpignata]

Thanks @joebernard! Are you seeing this locally in development during test or in production use?

[joebernard]

@jpignata I've only been able to test in development so far but the previous time this happened it was affecting production too. This only started breaking again after upgrading to 4.0.0. I tried rolling back but then started experiencing a different issue (#6145). I can't seem to get around that one either as it seems to persist through re-installs so I'm currently blocked.

[v1pz3n]

Also here

[v1pz3n]

Amplify updated to 3.3.10 and it worked

[joebernard]

Interesting. Maybe this is only broken in the modular packages. Unfortunately I cannot easily convert.

[njdullea]

I am not using modular packages, was on amplify 3.3.9 and encountered this issue. Updating to 3.3.10 did not resolve the issue.

Update: reverting to 3.3.8 resolved it for now.

[joebernard]

Can we get an update on how to proceed now that we are stuck with this artificial endpoint limit? Are we expected to manually manage this limit within Pinpoint somehow? What was the rationale behind removing this functionality? This has become a huge blocker for my team.

[jpignata]

Hi @joebernard - we're working on this with Pinpoint and will have more to share soon. Do you have anytime to chat tomorrow on discord perhaps? I'd like to learn more about the block and see if we can help. Happy Thanksgiving!

[joebernard]

@jpignata That would be helpful. I can meet anytime between 9:00 AM and 2:00 PM ET Nov 27. Happy Thanksgiving to you as well.

[sammartinez]

@joebernard Are you ok if we resolve this issue? Just wanted to validate if there were any other issues you were facing after our conversation last week. Please let us know

[joebernard]

Hi @sammartinez, thanks for asking. I would consider my case temporarily mitigated by rolling back, but the underlying issue re-introduced in @aws-amplify/analytics": "4.0.0" is still a problem. We uninstall / re-install apps so often that we quickly hit that 10 endpoint limit. It could also affect our production users though it would be more of an edge case. With no way for us to manage endpoints, this issue effectively breaks push notifications.

To me, this is a showstopper that precludes us from upgrading to 4.0.0 and beyond. We're locked into specific versions and might not be able to benefit from future features or security patches. I feel we either need some mechanism to manually manage endpoints, automated management of endpoints in Amplify or (preferably) in Pinpoint, or other guidance that would allow us to continue staying current with Amplify packages while avoiding this issue.

[v1pz3n]

I thought it worked but it was only in the web version.
For some reason, my react native on android and ios has the pinpoint error.

[dylan-westbury]

Hi @sammartinez, thanks for asking. I would consider my case temporarily mitigated by rolling back, but the underlying issue re-introduced in @aws-amplify/analytics": "4.0.0" is still a problem. We uninstall / re-install apps so often that we quickly hit that 10 endpoint limit. It could also affect our production users though it would be more of an edge case. With no way for us to manage endpoints, this issue effectively breaks push notifications.

I believe new endpoints not only occur when you uninstall apps, but just by clearing local storage.

For us, our big concern is that iOS users will stop receiving push notifications as we can't update the endpoint with the address with the new token.

[blacksheep--]

This is now the 5. incarnation of the very same topic. It seems this problem keeps popping up every other release. I guess it may be due to the fragile nature of the underlying code, where the returned message is string-checked to be starting with 'Exceeded maximum endpoint per user count' in AWSPinpointProvider.ts#461:

!String(message).startsWith('Exceeded maximum endpoint per user count')

A slight change of the message kills it, which already happened in the past.

Also OP seems absolutely right with his assumption that PR #7245 removed the clean-up of unused endpoints which worked perfectly before. How is this supposed to be handled?

[paddlefish]

Here's a manual workaround you can do using the CLI for each affected user:

step 1. Use cognito to search for the affected users sub

in this example i found user 719f397f-c6a6-4598-b603-7cc4d9d17911
also use pinpoint console to look up your analytics application id.

step 2. see how many endpoints are in pinpoint

aws --profile YourProfile pinpoint get-user-endpoints --user-id 719f397f-c6a6-4598-b603-7cc4d9d17911 --application-id daafcc04059a444aa9363e484113c189
{
"EndpointsResponse": {
"Item": [
{
"ApplicationId": "daafcc04059a444aa9363e484113c189",
"Attributes": {},
"CohortId
...

count them .. here i'm using jq and wc to count

➜ aws --profile YourProfile pinpoint get-user-endpoints --user-id 719f397f-c6a6-4598-b603-7cc4d9d17911 --application-id daafcc04059a444aa9363e484113c189| jq '.EndpointsResponse.Item[]|.Id' | wc
10 10 390

yup there are 10. so this user can't sign in due to this 10 endpoint restriction

step 3. Clear the oldest endpoints

3a. find the oldest ones. I scanned the list printed in step 2 and had manually found the newest endpoint creation date ('2020-12-18T19:45:48.212Z') to put in this expression:

 aws --profile YourProfile pinpoint get-user-endpoints --user-id 719f397f-c6a6-4598-b603-7cc4d9d17911 --application-id daafcc04059a444aa9363e484113c189| jq '.EndpointsResponse.Item[]|select(.CreationDate | contains("2020-12-18T19:45:48.212Z") | not)|.Id'

"3aa4dc90-2501-11eb-a16e-99d12931a92e"
"e5cd9240-276f-11eb-af3c-8130a9b73a99"
"3f66e740-2dae-11eb-aae4-153b561a5e3b"
"35b34700-2513-11eb-a296-0558d678e564"
"7ddf5e70-29cc-11eb-bdbf-671aec7e1f1f"
"94427fe0-3038-11eb-bf01-5b5367143dd5"
"2cbe3c00-3296-11eb-a617-23713ff6a6ee"
"50a2f3a0-357e-11eb-a551-958abb691880"
"3928cc60-3964-11eb-9bc3-bdabe9b761f6"

3b. use xargs to delete them

aws --profile YourProfile pinpoint get-user-endpoints --user-id 719f397f-c6a6-4598-b603-7cc4d9d17911 --application-id daafcc04059a444aa9363e484113c189| jq '.EndpointsResponse.Item[]|select(.CreationDate | contains("2020-12-18T19:45:48.212Z") | not)|.Id' -r
| xargs -n 1 aws --profile YourProfile pinpoint delete-endpoint --application-id daafcc04059a444aa9363e484113c189 --endpoint-id
{
"EndpointResponse": {
/* nine responses */

[dylan-westbury]

Receiving amplify security notification in AWS console but can't update due to this issue, we must stay on previous version otherwise user will eventually hit 10 endpoints and will no longer receive push notifications.

[joebernard]

@sammartinez Has there been any progress on this "exceeded maximum endpoint per user" issue"?

@dylan-westbury Which version of aws-amplify did you find avoids this issue? I'm using modules now but want to try that package instead.

[dylan-westbury]

Hi @joebernard

We upgraded aws-amplify and noticed this issue, so we downgraded back to the last working version we had within the app, which was:

"aws-amplify": "3.3.8",

We no longer received the "exceeded maximum endpoint per user" once we downgraded.

[maoosi]

I've recently updated to [email protected] (linking to @aws-amplify/[email protected]) and started having a similar errors showing in the console Exceeded maximum endpoint per user count: 15.

Would be nice to get someone from the amplify team commenting on the issue. Is there any config change that we need to apply in order to resolve this? Or is it a bug that need to be reverted as per suggested in aws-amplify/amplify-cli#5918?

[kylekirkby]

@the-smart-home-maker there definitely needs to be something done with this issue, it has been going on for way too long and needs some crazy "workarounds" that are not guaranteed to work :D

[yibb-y]

I got the same problem with amplify 4.3.12.

[ERROR] 51:10.543 AWSPinpointProvider - updateEndpoint failed Exceeded maximum endpoint per user count:15

The workaround worked partially #7251 (comment)
I had to delete all local storage objects. The aws-amplify-cacheCurSize, CognitoIdentityId...., aws-amplify-cacheAWSPinpoint...

It seems to be a problem with browsers who had these local storage objects set for a long time, using a different/new browser did not trigger the problem as well as deleting the local storage.

[nubpro]

Now is this 100% confirmed to be fixed with the latest PR by @hkjpotato?

@dylan-westbury Is this an error you still see on prod?

[dylan-westbury]

Hi @nubpro

Amplify version is 4.3.12
@aws-amplify/pushnotification version is 4.3.9

Were you expecting it to be fixed in these versions? This is in dev, but we are facing push notification issue in production.

What we notice is, overtime users will stop receiving push notifications in production. At first they will work, but then after some months they stop. So assuming the latest endpoint is not able to save once limit is reached, occasionally? Perhaps endpoints are changing from optOut NONE to ALL when creating a new endpoint?

As this issue has been ongoing for 2 years and there has been lots of instructions of how to implement on various Github issues that doesn't reflect what is shown in the documentation and lots of work arounds and hacks posted by everyone, is it possible to provide the exact expected way to implement and we can test that?

For example, do we still need to update the endpoint ourselves like this. For our use case, we request push permission once user is logged in in iOS and update when onRegister is called. But we also store in local storage and update providing it exists as well as the userId, because for Android the user may not be logged in when the token is received.

  Amplify.configure({
    ...awsmobile,
    PushNotification: {
      requestIOSPermissions: false,
      appId: awsmobile.aws_mobile_analytics_app_id,
    },
  });

 PushNotification.onRegister(async (token) => {
    console.log("in app registration", token);

    await updatePushToken(token);
  });

  const updatePushToken = async (token) => {
    try {
      let user;
      try {
        user = await getCurrentAuthenticatedUser();
      } catch (err) {
        console.log("error getCurrentAuthenticatedUser: ", err);
      }

      if (user && user.username) {
        const options = {
          optOut: "NONE",
          address: token,
          userId: user.username
        };

        await Analytics.updateEndpoint(options);
        await AsyncStorage.setItem("xxxxxxx-xxxxxx-amplifyPushToken", token);
      }
    } catch (err) {
      console.log("error updating address for push", err);
    }
  };

Or can we depend on @aws-amplify/pushnotification to do this for us?

Or another preferred suggestion?

[abdallahshaban557]

FYI @Samaritan1011001 ^

[kylekirkby]

@josefaidt - any chance you can take a look at this issue? 🙏🏼

[joebernard]

Can we get an update on this? Is Amplify now managing Pinpoint endpoints correctly or do we need to do it manually? Trying to weigh using Amplify on a new project and this is a deal breaker.

[franklt69]

Hi,

issue: AWSPinpointProvider - updateEndpoint failed Exceeded maximum endpoint per user count:15

   aws-amplify: ^4.3.14 => 4.3.14 
    aws-amplify-angular: ^5.0.53 => 5.0.56 

I am using analytics in the following way:

const awsmobile = {
    "aws_project_region": "us-east-2",
    "aws_cognito_identity_pool_id": “xx”,
    "aws_cognito_region": "us-east-2",
    "aws_user_pools_id": "xxxx”,
    "aws_user_pools_web_client_id": “xxxx”,
    "oauth": {},
    "aws_appsync_graphqlEndpoint": "https://xxxx/graphql",
    "aws_appsync_region": "us-east-2",
    "aws_appsync_authenticationType": "AMAZON_COGNITO_USER_POOLS",
    "aws_mobile_analytics_app_id": “xxxxxxx”,
    "aws_mobile_analytics_app_region": "us-east-1"

};
export default awsmobile;

app.module.ts

/* Configure Amplify resources */
amplify.configure(awsconfig);

then later, I start recording my analytics:

import {Analytics} from 'aws-amplify';

                analytics.record({
                     name: 'addCreditCardView.enrolled.success',
                     attributes: {
                       content: 'action-viewEnrolling-Success',
                       user: this.globalService.email,
                       appName: this.globalService.appName,
                       appVersion: this.globalService.appVersion
                     },
                     metrics: {time: this.globalService.utcLocal},
                   });

Using the application in the browser with the localstorage clear (no cookies), when I log in, I can see the events that are called to pinpoint without problems; now I just refresh the browser and start to get:

AWSPinpointProvider - updateEndpoint failed Exceeded maximum endpoint per user count:15

If I log out, clean the localstorage, and log in again, everything is ok; I refresh the browser, and the problem comes back.

Can someone tell me what the best practices to record analytics with pinpoint are? I'm not using it for notifications, just to record analytics.

And after reading this thread I'm not clear if any version of amplify it solves the problem or if after almost two years the problem persists.

Thanks
Frank

more info:

System:
OS: macOS 12.2
CPU: (12) x64 Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz
Memory: 233.02 MB / 32.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 14.21.1 - ~/.nvm/versions/node/v14.21.1/bin/node
Yarn: 1.22.10 - /usr/local/bin/yarn
npm: 6.14.17 - ~/.nvm/versions/node/v14.21.1/bin/npm
Browsers:
Chrome: 108.0.5359.124
Safari: 15.3
Safari Technology Preview: 15.4
npmPackages:
@angular-devkit/build-angular: ^0.1000.8 => 0.1000.8
@angular-devkit/schematics: ^12.0.5 => 12.1.2
@angular/cli: ~10.0.5 => 10.0.8
@angular/common: ~10.0.0 => 10.0.14
@angular/compiler: ~10.0.0 => 10.0.14
@angular/compiler-cli: ~10.0.0 => 10.0.14
@angular/core: ~10.0.0 => 10.0.14
@angular/forms: ~10.0.0 => 10.0.14
@angular/language-service: ~10.0.0 => 10.0.14
@angular/platform-browser: ~10.0.0 => 10.0.14
@angular/platform-browser-dynamic: ~10.0.0 => 10.0.14
@angular/router: ~10.0.0 => 10.0.14
@capacitor-community/barcode-scanner: ^3.0.0 => 3.0.0
@capacitor/android: ^4.3.0 => 4.3.0
@capacitor/browser: ^4.0.1 => 4.0.1
@capacitor/cli: ^4.3.0 => 4.3.0
@capacitor/clipboard: ^4.0.1 => 4.0.1
@capacitor/core: ^4.3.0 => 4.3.0
@capacitor/ios: ^4.3.0 => 4.3.0
@capacitor/push-notifications: ^4.0.0 => 4.1.0
@capacitor/splash-screen: ^4.1.0 => 4.1.0
@capacitor/status-bar: ^4.0.1 => 4.0.1
@capacitor/toast: ^4.0.1 => 4.0.1
@ionic-native/card-io: ^5.36.0 => 5.36.0
@ionic-native/core: ^5.0.0 => 5.27.0
@ionic-native/fingerprint-aio: ^5.33.1 => 5.33.1
@ionic-native/in-app-browser: ^5.27.0 => 5.27.0
@ionic-native/splash-screen: ^5.0.0 => 5.27.0
@ionic-native/status-bar: ^5.0.0 => 5.27.0
@ionic-native/theme-detection: ^5.28.0 => 5.28.0
@ionic/angular: ^5.0.0 => 5.2.3
@ionic/angular-toolkit: ^2.3.0 => 2.3.3
@ionic/storage-angular: ^3.0.6 => 3.0.6
@ngx-translate/core: ^13.0.0 => 13.0.0
@ngx-translate/http-loader: ^6.0.0 => 6.0.0
@schematics/angular: ^9.1.0 => 9.1.0
@types/jasmine: ~3.5.0 => 3.5.11
@types/jasminewd2: ~2.0.3 => 2.0.8
@types/node: ^12.11.1 => 12.12.47
amplify-i18n: ^0.3.0 => 0.3.0
aws-amplify: ^4.3.14 => 4.3.14
aws-amplify-angular: ^5.0.53 => 5.0.56
card.io.cordova.mobilesdk: ^2.1.0 => 2.1.0
codelyzer: ^6.0.0 => 6.0.1
cordova: ^9.0.0 => 9.0.0
cordova-ios: ^4.5.5 => 4.5.5
cordova-plugin-device: ^2.0.2 => 2.0.3
cordova-plugin-fingerprint-aio: 5.0.1 => 5.0.1
cordova-plugin-iroot: ^2.1.0 => 2.1.0
cordova-plugin-theme-detection: ^1.2.1 => 1.2.1
cordova-res: ^0.15.1 => 0.15.1
core-js: ^2.5.4 => 2.6.11
dayjs: ^1.10.8 => 1.10.8
flag-icon-css: ^3.5.0 => 3.5.0
google-libphonenumber: ^3.2.30 => 3.2.30
ion-intl-tel-input: ^1.0.5 => 1.0.5
ionic-selectable: ^4.9.0 => 4.9.0
jasmine-core: ~3.5.0 => 3.5.0
jasmine-spec-reporter: ~5.0.0 => 5.0.2
jetifier: ^1.6.5 => 1.6.6
jose-jwe-jws: ^0.1.6 => 0.1.6
karma: ~5.0.0 => 5.0.9
karma-chrome-launcher: ~3.1.0 => 3.1.0
karma-coverage-istanbul-reporter: ~3.0.2 => 3.0.3
karma-jasmine: ~3.3.0 => 3.3.1
karma-jasmine-html-reporter: ^1.5.0 => 1.5.4
ng-circle-progress: ^1.6.0 => 1.6.0
payform: ^1.4.0 => 1.4.0
protractor: ~7.0.0 => 7.0.0
rxjs: ~6.5.5 => 6.5.5
snyk: ^1.870.0 => 1.870.0
ts-node: ~8.3.0 => 8.3.0
tslib: ^2.0.0 => 2.4.0
tslint: ~6.1.0 => 6.1.2
typescript: ~3.9.5 => 3.9.7
zone.js: ~0.10.3 => 0.10.3
npmGlobalPackages:
corepack: 0.14.2
npm: 6.14.17

[abdallahshaban557]

Hello everyone, we are working with the Pinpoint team to alleviate this issue. In the future, the Pinpoint team is going to allow events to be recorded at the "User" level rather than at the endpoint, which would mean that the creation of the 15 endpoints would be significantly less prone to happen since an endpoint would not be required for recording analytics events. We will keep you updated when we have a path forward.

[BabyDino]

That is great news. Looking very much forward to that!

[franklt69]

Thanks for your update, meanwhile is there any recommendation to fix this limitation?

[abdallahshaban557]

To get around this now, you would need to use the AWS SDK and directly interact with Pinpoint to cleanup any unused endpoints for a specific userID. The only issue is identifying WHICH endpoints are actually unused, Pinpoint does not provide that information by default in the Endpoint information, so you will have to create some mechanism to detect that - maybe by using a custom attribute for example on the Endpoints to capture that.

[gspeicher]

FWIW, we have had success by using the following to configure Amplify Analytics:

Amplify.configure({
    ...awsmobile,
    Analytics: {
      AWSPinpoint: {
        appId: awsmobile.aws_mobile_analytics_app_id,
        region: awsmobile.aws_mobile_analytics_app_region,
        endpointId: uniqueId,
      },
    },
  });

where uniqueId is the result of a call to DeviceInfo.getUniqueId() from the react-native-device-info package. This effectively gives you one single endpoint per device.

[franklt69]

Hi gspeicher, thanks for your suggestion, I'm going to try it, but first I have a question, the user I'm testing is giving me this error, how could I delete the endpoints for that user in pinpoint?

[wasurocks]

Hi gspeicher, thanks for your suggestion, I'm going to try it, but first I have a question, the user I'm testing is giving me this error, how could I delete the endpoints for that user in pinpoint?

Hey there, one of the possible options is to clear it via the SDK (@aws-sdk/client-pinpoint) via the DeleteUserEndpointsCommand. Here is the documentation for it. However, I think this is still inconvenient as it is not automatically done 🥲

[abdallahshaban557]

Hi @wasurocks - we completely agree with you, this is extremely frustrating. We are working closely with the Pinpoint team to get this resolved. We will provide timelines on when we expect this issue to be resolved.

[BabyDino]

Hi @abdallahshaban557, any news on this issue?

[SwhiteMHC]

Hi. Are there any updates on this issue? I am seeing this problem in "aws-amplify": "6.0.5".

[cunneen]

[irfancnk]

Hello @abdallahshaban557, we are also facing this issue with version 6.0.28, wanted to check in here since it's been nearly a year since we've seen any updates from the maintainers. Are there any team members currently addressing this issue, or could you suggest a potential workaround?

[abdallahshaban557]

Hi @irfancnk - I am no longer a part of the Amplify team - I am adding @haverchuck /@renebrandel/ @cwomack to help answer this for you.

[julian-dotcom]

Any updates on this?

[rpungin]

I am getting this error as well. But I still seem to get the notifications. This issue has been open for 4 years. Is this error benign?

[tnkgs]

Using identifyUser worked well.

import { record, identifyUser } from "aws-amplify/analytics";
...
await identifyUser({
  userId: userInfo.username,
});

[davidspica]

Any update on this? We're experiencing the same issue due to browser cache getting cleared frequently.