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

[sammartinez]

Thanks for this feedback everyone, I am sharing this feedback with the Amazon Pinpoint team since they should handle this within the Service. Will provide an update early next week or once I hear something.

[BabyDino]

FYI, I am now seeing 13 endpoints for 1 user. I am not seeing any errors, but I also don't see a purge of stale endpoints.

[nubpro]

Hi, is this issue resolved 100%?

Can I use pinpoint now?

[GeorgeBellTMH]

I received this error - exceeded maximum endpoints per user count: 15 just 39 hours ago...I don't believe it is fixed.

[gspeicher]

I'm getting this error with @aws-amplify/analytics 4.0.22 so it doesn't seem to be fixed for me either.

[satbirsab]

any update?

[kylekirkby]

@sammartinez - I'm also still getting this error when making a call to update an endpoint..

    "aws-amplify": "^4.1.1",

          Analytics.updateEndpoint({
            address: user.attributes.email,
            channelType: "EMAIL",
            optOut: "NONE",
            userId: user.attributes.sub,
          }).catch((error) => {
            console.log(error);
          });

[damien-monni]

I am getting this error with aws-amplify 4.1.3

[gspeicher]

FWIW, I've discovered that you can sidestep this issue by specifying your own endpointId to override the one that Amplify is assigning by default. If you're using React Native, this could be as simple as:

import DeviceInfo from 'react-native-device-info';

Amplify.configure({
  ...awsmobile,
  Analytics: {
    AWSPinpoint: {
      appId: awsmobile.aws_mobile_analytics_app_id,
      region: awsmobile.aws_mobile_analytics_app_region,
      endpointId: DeviceInfo.getUniqueId(),  // overrides the default Amplify-generated endpoint ID
    },
  },
});

Then your user will get a unique (and unchanging) endpoint for each device they use to access your app, which is desirable for per-device push notifications.

This solution will still break if the user has too many devices, but it works for the overwhelming majority. Futhermore, where it falls down, we are arguably viewing the problem as a Pinpoint limitation rather than an Amplify bug.

[satbirsab]

work-around There is work around we have used for our project until actual fix come for this problem.

[dylan-westbury]

FWIW, I've discovered that you can sidestep this issue by specifying your own endpointId to override the one that Amplify is assigning by default. If you're using React Native, this could be as simple as:

import DeviceInfo from 'react-native-device-info';

Amplify.configure({
  ...awsmobile,
  Analytics: {
    AWSPinpoint: {
      appId: awsmobile.aws_mobile_analytics_app_id,
      region: awsmobile.aws_mobile_analytics_app_region,
      endpointId: DeviceInfo.getUniqueId(),  // overrides the default Amplify-generated endpoint ID
    },
  },
});

Then your user will get a unique (and unchanging) endpoint for each device they use to access your app, which is desirable for per-device push notifications.

This solution will still break if the user has too many devices, but it works for the overwhelming majority. Futhermore, where it falls down, we are arguably viewing the problem as a Pinpoint limitation rather than an Amplify bug.

Do you know if the optOut remains as "NONE" for the endpoint and not "ALL"?

[dylan-westbury]

I have noticed for some users:

• They have 14 - 15 "ACTIVE" endpoints, even some dating back more than a year ago to a device that is old / no longer in possession OR an older version of the operating system.

For example, I can see for a single user the following active endpoints for a single device "iPhone X":

• 1 active endpoint for iOS 13.6
• 6 active endpoints for iOS 14.4.2
• 7 active endpoints for iOS 14.6

I read pinpoint documentation, an endpoint will only change to "INACTIVE" when an existing "address" is added to a new endpoint. This can be problematic because iOS refreshes the push token which is used as the address for an endpoint, so an endpoint with an old address / token can remain ACTIVE.

I also noticed some new endpoints have changed from optOut "NONE" to "ALL" over time, I don't think that should be happening because each time the token refreshes we update the optOut to "NONE". Could endpoints be changing from "NONE" to "ALL" ?

This is our code to update endpoint address with push token.

const updatePushToken = async (token) => {
    try {
      const user = await getCurrentAuthenticatedUser(); // calls Auth.currentAuthenticatedUser

      if (user && user.username) {
        const options = {
          optOut: 'NONE',
          address: token,
          channelType: Platform.OS === 'ios' ? 'APNS' : 'GCM',
          userId: user.username
        };

        await Analytics.updateEndpoint(options);
      }
    } catch (err) {
      console.log('error getCurrentAuthenticatedUser ', err);
    }

    await AsyncStorage.setItem('amplifyPushToken', token);
  };

We ask for push notification permissions when user is logged in also, but as a safety we save the token in storage and update the endpoint with that token (if it exists) from async storage in case for whatever reason a new endpoint is created without the address as the token.

We also set the user session to expire after a very long while, so there isn't any conflict with the user having to log back in and mess up the existing endpoint in some way

[kylekirkby]

@sammartinez any update on this? Still experiencing this with the latest release...

[GeorgeBellTMH]

A full year in and we still need-discussion and investigating....when they had something that worked before...better get the pinpoint team to re-design their entire system instead of leaving in the 3 lines of code that fixed this....

[kylekirkby]

A full year in and we still need-discussion and investigating....when they had something that worked before...better get the pinpoint team to re-design their entire system instead of leaving in the 3 lines of code that fixed this....

I ended up creating an elaborate stack to export the endpoints and then remove duplicate onces. The problem, I believe will lie in how the endpoints are being updated in your app. There were a few attributes that I needed to "blank" in order to prevent pinpoint from creating new endpoints constantly. Specifically, the version of the Chrome Web Browser changing often resulted in a new endpoint being created every time chrome updates.

import { Analytics } from "aws-amplify";
import { getCurrentUser } from "lib/auth";

export const startAnalytics = async () => {
  let userObject = await getCurrentUser();
  try {
    let res = await Analytics.updateEndpoint({
      address: userObject["user"].attributes.email,
      channelType: "EMAIL",
      optOut: "NONE",
      userId: userObject["user"].attributes.email,
      demographic: {
        modelVersion: "", // The model version of the endpoint device.
        appVersion: "",
      },
    });
    console.log("Analytics endpoint updated: ", res);
    return res;
  } catch (err) {
    console.log("USER EMAIL: ", userObject["user"].attributes.email);
    console.log(err);
  }
};

In my admin dashboard I've got an export endpoints button:

const exportPinpointEndpoints = async (event, callback) => {
  var pinpoint = new AWS.Pinpoint();
  var params = {
    ApplicationId: process.env.ANALYTICS_XXXXXXXXXX_ID,
    ExportJobRequest: {
      /* required */
      RoleArn: process.env.PINPOINT_S3_EXECUTION_ROLE /* required */,
      S3UrlPrefix: `s3://${process.env.STORAGE_USERASSETS_BUCKETNAME}/exports/` /* required */,
      // SegmentId: "STRING_VALUE",
      // SegmentVersion: "NUMBER_VALUE",
    },
  };
  console.log(params);
  let res = await pinpoint.createExportJob(params).promise();
  console.log(res);
  callback(null, JSON.stringify(res));
};

Then I've got an s3 trigger to process the gzip exports...

const processPinpointEndpointExport = async (event, key, bucket) => {
  const params = {
    Bucket: bucket,
    Key: key,
  };
  console.log("Params: ", params);
  try {
    let res = await s3.getObject(params).promise();
    console.log(res);
    let unzipRes = await gunzip(res.Body);
    console.log(unzipRes);
    let string = unzipRes.toString("utf8");
    console.log(string);
    let arrayOfEndpoints = string.split("\n").map((stringJson) => {
      try {
        if (stringJson.length > 0) {
          return JSON.parse(stringJson);
        }
      } catch (err) {
        console.log("Error parsing: ", stringJson);
      }
    });
    console.log(arrayOfEndpoints);
    let filteredEndpoints = arrayOfEndpoints.filter((item) => {
      try {
        if (Object.prototype.hasOwnProperty.call(item, "Address")) {
          if (item.Address === "send@kyle.news") {
            return item;
          }
        }
      } catch (err) {
        console.log(err);
        console.log(item);
      }
    });
    console.log("Filtered: ", filteredEndpoints);
    console.log("Filtered len: ", filteredEndpoints.length);
    console.log("Sorted: ", filteredEndpoints.sort(compareEndpointsByDate));
    let oldestEndpoints = filteredEndpoints.slice(1, filteredEndpoints.length);
    console.log("Oldest endpoints:", oldestEndpoints);
    console.log("Oldest endpoints length:", oldestEndpoints.length);
    let deletePromises = [];
    for (let i = 0; i < oldestEndpoints.length; i++) {
      deletePromises.push(deleteEndpoint(oldestEndpoints[i]));
    }
    await Promise.all(deletePromises);
    console.log("Oldest endpoints have been deleted.");
  } catch (err) {
    console.log(err);
  }
};

It's not perfect code since I hacked it together late at night with frustration :D

Depending on your app requirements, it may be a good idea to be able to export endpoints anyway for marketing purposes.

Setting up the S3 execution role for Pinpoint to assume is a bit fiddly but I've done this all with amplify / custom CloudFormation templates.

[hkjpotato]

For web, the endpoint id is created and cached in local storage.

Normally it will be persisted so you should not run into the issue of creating another endpoint and reach limit, but if you are using Incognito or manually clean the localStorage, then the endpoint id will be recreated.

For now, if the endpoint channel type is "PUSH" ( e.g. ADM, PUSH, GCM, APNS, APNS_VOIP, APNS_VOIP_SANDBOX, BAIDU), then pinpoint will auto evict it if there are more than 15 endpoints associated with the userId (by default, Amplify use the identity id from identity pool as the userId).

The auto eviction won't apply to the "Email" channel type though. In this case, we need to delete the overflowed endpoints if they reach the limits.

[BabyDino]

Thanks for the clarification. But since when is this active? Because 1 have one EMAIL, 1 TEL and 13 GCM (due to testing), and ran into the error 2 weeks ago...

[hkjpotato]

Thanks for the clarification. But since when is this active? Because 1 have one EMAIL, 1 TEL and 13 GCM (due to testing), and ran into the error 2 weeks ago...

Hi, thanks for the information. I am still trying to understand the root cause of it by talking to pinpoint team. Can you help me confirm if it is the case:

1. You have one user id linked to 15 endpoints now (13 GCM, 1 TEL, 1 Email) and you cannot add new endpoints to the same user.
2. In testing are you deleting the endpoint id in storage? Are you using react-native or just web js?

[phuctm97]

Thanks for clarifying @hkjpotato, can you also clarify that are INACTIVE endpoints counted in maximum endpoints and will Pinpoint ever auto-delete INACTIVE endpoints?

[hkjpotato]

Thanks for clarifying @hkjpotato, can you also clarify that are INACTIVE endpoints counted in maximum endpoints and will Pinpoint ever auto-delete INACTIVE endpoints?

As far as I know, INACTIVE endpoint will only be created if you have two endpoints with same "address". The problem here is Pinpoint is doing auto-delete based on channel type, not INACTIVE status.

[the-smart-home-maker]

Is there any update on this issue? I am still running into this issue with aws-amplify 4.3.8:

Strangely, even after deleting all endpoints for the given user with aws pinpoint delete-user-endpoint ..., the problem persists...

[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 https://github.com/aws-amplify/amplify-js/issues/7251#issuecomment-878352384 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,
});