Conversation
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| if (data?.url) { | ||
| url = data.url as string; | ||
| } else if (data?.nid) { | ||
| url = Linking.createURL(`notifications/${data.nid}`); | ||
| } else { |
There was a problem hiding this comment.
Bug: Notification deep linking is broken when the app is launched from a killed state because the handling logic was removed from getInitialURL.
Severity: CRITICAL
Suggested Fix
Restore the logic within the getInitialURL function in src/navigation/linking.ts. It should await Notifications.getLastNotificationResponseAsync() and process the response to return the correct initial deep link path, ensuring notification taps from a killed app state are handled correctly.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/hooks/use-notification-deep-link.ts#L24-L28
Potential issue: The logic to handle notification deep links when the app is launched
from a killed state has been removed from `getInitialURL`. Previously, `getInitialURL`
would check for a notification response using
`Notifications.getLastNotificationResponseAsync()`. The new implementation returns
`null` and relies on the `useNotificationDeepLink` hook, which executes too late in the
app's startup sequence to handle this cold-start scenario. Consequently, when a user
taps a notification while the app is not running, they will be directed to the default
initial screen instead of the content specified in the notification.
Did we get this right? 👍 / 👎 to inform future reviews.
| shouldPlaySound: true, | ||
| shouldSetBadge: false, | ||
| }), | ||
| handleSuccess: async (nid) => { | ||
| console.log("Recived push notification in foreground with id: ", nid); | ||
| queryClient.invalidateQueries({ queryKey: ["notifications"] }); | ||
|
|
||
| Toast.show({ | ||
| type: "info", | ||
| text1: "New notification recived!", | ||
| text2: "Take a look at your inbox", | ||
| onPress() { | ||
| navigation.navigate("InboxStack", { screen: "Inbox" }); | ||
| }, | ||
| }); | ||
| }, | ||
| handleError: async (nid, error) => | ||
| console.error( | ||
| "Error when reciving push notification in foreground with id: ", | ||
| nid, | ||
| error | ||
| ), | ||
| }); | ||
|
|
||
| useEffect(() => { | ||
| const subscription = Notifications.addNotificationReceivedListener( | ||
| (notification) => { | ||
| console.log( |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
| useEffect(() => { | ||
| if ( | ||
| lastNotificationResponse && | ||
| lastNotificationResponse.notification.request.identifier !== | ||
| previousResponseId.current | ||
| ) { | ||
| // Update the ref to track we've handled this notification | ||
| previousResponseId.current = | ||
| lastNotificationResponse.notification.request.identifier; |
There was a problem hiding this comment.
Bug: The app re-navigates to the last notification on every restart from a killed state because the previousResponseId ref is reset while the notification response persists.
Severity: HIGH
Suggested Fix
After successfully handling the notification deep link, call Notifications.clearLastNotificationResponseAsync() to clear the persisted notification response. This will prevent it from being processed again on subsequent app launches.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/hooks/use-notification-deep-link.ts#L10-L18
Potential issue: The `useNotificationDeepLink` hook will cause unexpected navigation
when the app is restarted after being force-closed. The hook uses
`Notifications.useLastNotificationResponse()` to get the last notification, which
persists even after the app is killed. However, the `previousResponseId` ref, used to
prevent re-processing the same notification, is reset to `null` every time the app
launches. This causes the hook to re-trigger navigation to the old notification on every
app start, as the check `lastNotificationResponse.notification.request.identifier !==
previousResponseId.current` will evaluate to true.
1 participant
No description provided.