Notifications channel and group issue

[DSp4wN]

Minimal reproducible example

https://github.com/DSp4wN/Expo-notification-test

Extract the files and just run as usual expo app add your own firebase service account to test it out through sdk

What platform(s) does this occur on?

Android

Did you reproduce this issue in a development build?

Yes

Summary

I am doing this for first time so if there is any mistake / wrong approach please let me know. (Thanks in advance)

So normally the notification is working as it is expected to with default channel, I am getting all the notifications but the problem is they are all being stacked together in one single notification. Now what I am trying to do is,
i) I made 2 separate channels one for messages and one for normal notifications
ii) for the messages I am passing the following payload through expo-sdk in my nodejs api
{
to: token,
sound: 'default',
title: title,
body: body,
data: data,
channelId: 'messages',
groupId: data.conversationId,
android: {
channelId: 'chat-messages',
group: data.conversationId, // Group by conversation ID
},
ios: {
_displayInForeground: true,
threadId: data.conversationId
},
threadIdentifier: data.conversationId
}

So as per the separate channel and groupId (Android) / threadId (iOS), I think I should be seeing different notification for different channels ? but I am seeing all notifications still getting stacked in one single notification.

I am trying to make it behave something like whatsapp has, one single notification for a single conversation containing all the messages (notifications of the same conversation) as a thread in it.

Please let me know what's going wrong here or what different approach I have to proceed with?

These are my package versions:

"dependencies": {
"@react-native-async-storage/async-storage": "^1.23.1",
"@react-native-community/netinfo": "^11.3.1",
"axios": "^1.6.8",
"expo": "~50.0.13",
"expo-constants": "~15.4.5",
"expo-device": "~5.9.3",
"expo-file-system": "^16.0.9",
"expo-notifications": "~0.27.6",
"expo-sharing": "^11.10.0",
"expo-status-bar": "~1.11.1",
"react": "18.2.0",
"react-native": "0.73.5",
"react-native-gesture-handler": "^2.16.0"
},
"devDependencies": {
"@babel/core": "^7.20.0",
"@types/react": "~18.2.45",
"typescript": "^5.1.3"
},

Environment

expo-env-info 1.2.0 environment info:
System:
OS: Windows 11 10.0.22000
Binaries:
Node: 18.17.1 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
npm: 10.5.0 - C:\Program Files\nodejs\npm.CMD
IDEs:
Android Studio: AI-221.6008.13.2211.9619390
npmPackages:
expo: ~50.0.13 => 50.0.17
react: 18.2.0 => 18.2.0
react-native: 0.73.5 => 0.73.5
Expo Workflow: bare

Expo Doctor Diagnostics

✔ Check Expo config for common issues
✔ Check package.json for common issues
✔ Check native tooling versions
✔ Check dependencies for packages that should not be installed directly
✔ Check for common project setup issues
✔ Check that native modules do not use incompatible support packages
✔ Check npm/ yarn versions
✔ Check for issues with metro config
✔ Check for legacy global CLI installed locally
✔ Check Expo config (app.json/ app.config.js) schema
✔ Check that native modules use compatible support package versions for installed Expo SDK
✖ Check that packages match versions required by installed Expo SDK

Detailed check results:

The following packages should be updated for best compatibility with the installed expo version:
@react-native-async-storage/async-storage@1.23.1 - expected version: 1.21.0
@react-native-community/netinfo@11.3.1 - expected version: 11.1.0
react-native@0.73.5 - expected version: 0.73.6
react-native-gesture-handler@2.16.0 - expected version: ~2.14.0

[expo-bot]

Thank you for filing this issue!
This comment acknowledges we believe this may be a bug and there’s enough information to investigate it.
However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.