-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't update optOut for AWS Pinpoint endpoint without address (APNs device token) #13272
Comments
Hello, @victoravr and thank you for opening this issue. Can you confirm if you also see this happen when you set This does seem to be a bug and we'll investigate this as such. The address should not be required per Pinpoint's documentation. |
Hi @victoravr. As @cwomack mentioned, we are currently treating this as a bug, however I am unable to reproduce the error via the steps below:
Could you please share more of your use case with us so we can better reproduce the circumstances around which you are seeing the issue? It would also be helpful if you could use Flipper or something similar to inspect the actual network calls being made? In particular - we want to be sure that the endpointId of the calls are consistent between calls E.g.
|
Sorry, haven't tried setting And yes, initializePushNotifications() is called before identifyUser() call. |
Hmm, could you try to reproduce the error on the physical device, if possible? I have noticed this error while testing on iPhone Xr with iOS 17.4.1. |
OK, I have updated identifyUser() call to set optOut to 'ALL' upon user sign-out. During testing this time I can't reproduce the reported error - neither for 'NONE', nor for 'ALL' optOut without address. If you can't reproduce it on the physical device too, happy to close this issue - maybe it was a bug in my code. Thanks! |
Appreciate the confirmation, @victoravr. We haven't been able to reproduce it on out side either following the documented flows. We'll close this issue out for now, but feel free to reply back if you happen to find a way to reproduce it reliably again! |
Hmm is this the first network call to Pinpoint being made by the application? When initializing push notifications, there should be a call made automatically to bootstrap the endpoint with the token (address). Would it be possible to add a onTokenReceived handler to check if the token is being received? How early on is the initializePushNotifications call being made in the lifecycle of your application? What is supposed to happen is:
It seems like somehow step 4 either did not trigger or did not complete in time 🤔 so it would be helpful to know if there are any other calls being made by the library at all.. |
Thanks for prompt reply, @cshfang!
Yes, looks like it was the first network call to Pinpoint made by the app since launch.
I've got onTokenReceived used inside useEffect of the React component, as below: import React, {useEffect} from 'react';
import {
onTokenReceived,
OnTokenReceivedInput,
OnTokenReceivedOutput,
} from 'aws-amplify/push-notifications';
import {setDeviceToken} from './src/redux/deviceToken';
import {useDispatch} from 'react-redux';
export const RegisterToken = () : React.JSX.Element => {
const dispatch = useDispatch();
useEffect(() => {
const tokenReceivedHandler: OnTokenReceivedInput = token => {
// Do something with the received token
console.log(token, 'token');
dispatch(setDeviceToken(token));
};
const tokenListener: OnTokenReceivedOutput =
onTokenReceived(tokenReceivedHandler);
return () => {
tokenListener.remove();
};
}, []);
// @ts-ignore
return <></>;
}; then in App.tsx: ...
import {RegisterToken} from './RegisterToken';
...
// @ts-ignore
return (
<>
<Provider store={store}>
<PersistGate loading={<Text>Loading...</Text>} persistor={persistor}>
<QueryClientProvider client={queryClient}>
<SafeAreaProvider>
<ThemeProvider theme={theme}>
<RegisterToken />
<AppNavigation />
</ThemeProvider>
</SafeAreaProvider>
</QueryClientProvider>
</PersistGate>
</Provider>
<Toast />
</>
);
... Is this approach supported? |
Hey @victoravr.
Is there a network call made afterwards? Where in the application are you calling |
After testing this out, I do think we have a potential race condition if
Issue 2 is a bit hairier to resolve as it is not clear to me why the Pinpoint service does not allow the use case of opting an endpoint out before attaching an address to it. So I am in contact with the Pinpoint team regarding this. Pending their response, I will work on evaluating possible solutions to this. In the meantime, since you are listening for a token, I think a potential fix in the meantime could be to pass that token in along with your |
Hi @cshfang,
Yes, looks like there was a call after that with address: {
"RequestId": "7d62b64a-bcca-48cd-872f-db17b3bcdca3",
"EffectiveDate": "2024-04-28T01:04:49.043Z",
"ChannelType": "APNS_SANDBOX",
"Address": "80042cfb1a57d0426ad71ebe50...663931ca806",
"Demographic": {
"AppVersion": "ios/17.4",
"Make": null,
"Model": null,
"ModelVersion": "17.4",
"Platform": "ios"
},
"Location": {},
"User": {
"UserId": "ap-southeast-2:7de8bcb7-b604-cd23-5116-5211a83a494f"
}
}
I'm calling initializePushNotifications(); in root index.js after Amplify.configure(...); but before AppRegistry.registerComponent(appName, () => App); As for identifyUser, it's inside useEffect in AppNavigation.js: ...
useEffect(() => {
if (user) {
if (user.userId) {
identifyUsertoPinpoint({
deviceToken: deviceToken,
userId: user.userId,
optOut: 'NONE'
});
};
};
}, [user, deviceToken]);
... |
I think the network call happening out of order is consistent with my findings. However, I noticed that you are already sending the device token along with your identifyUser call. I don't know what the exact body of your
|
Thanks! Updated my code to only do API request with OptOut if deviceToken is not empty/null. Question: when device token is sent to the end user device/simulator for APNs (e.g. in a Sandbox)? At least on simulator, I've noticed it does not appear at all sometimes... |
It should be invoked when |
Hi @victoravr Amplify JS v6.3.1 has just been released. It should contain the following fixes: We believe these fixes should resolve your issue of the |
Hi @cshfang , I've installed Amplify JS v6.3.1, and tested my app on a physical iPhone device. Unfortunately, notifications did not work initially due to a token not being issued after launching the app. I had to close the app, re-launch it, sign-in as AWS Cognito user, then minimize it and re-open - and only then APNs token had been issued... not sure why this is the case.. Any advise? |
Hmm there should definitely be no reason for a need to sign in as a user as the endpoints are tied to device. Was the token not issued from a fresh install? We are responding to the Could you try to add NSLog to your AppDelegate to make sure that |
@victoravr Thanks for your patient on this stuff, by the way. Would you mind opening a separate ticket to track the token issue? Given that I have seen similar behavior on simulator with iOS 17, I am wondering if something changed in the bootstrapping behavior of the observers which fire the registration call in the native layer. It would be helpful if we could track the investigation of this on a ticket dedicated to that. |
Before opening, please confirm:
JavaScript Framework
React Native
Amplify APIs
Push Notifications
Amplify Version
v6
Amplify Categories
notifications
Backend
CDK
Environment information
Describe the bug
Can't update optOut for AWS Pinpoint endpoint without address (APNs device token)
Expected behavior
Should be able to update optOut (e.g. set to 'NONE') for AWS Pinpoint endpoint without address (APNs device token)
Reproduction steps
call identifyUser() after user logs in.
If no device token provided along with optOut option as address, console warning appears as in screenshot.
Code Snippet
Log output
aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
iPhone 15 Pro + Simulator
Mobile Operating System
iOS 17.4
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
The text was updated successfully, but these errors were encountered: