Marking feed notifications as read/seen does not return updated data

• Version: 5+
• System: Node.js

What steps will reproduce the bug?

Mark individual or groups of notifications as read/seen returns unchanged data

client.feed('notification', feedId).get({ limit: 10, mark_read: notificationId })
client.feed('notification', feedId).get({ limit: 10, mark_seen: true })

or directly…

https://api.stream-io-api.com/api/v1.0/enrich/feed/notification/[userId]/?api_key=[key]&limit=10&mark_read=0fd5ag06-7677-11eb-8080-800096ace01e.like_2021-01-13

What is the expected behavior?

Endpoint returns data with specific notifications marked true is_read: true

What do you see instead?

is_read property is still false. A second call for fresh notification data is required.

Additional details

Seeing the same behavior for marking notifications “seen”

gz#9687

[micha3ldavid]

@tbarbugli Sorry, it still doesn’t make sense to me.

If I make a request to fetch a list of notifications along with the unseed and unread fields, I am not going to pass the mark_read=true or mark_seen=true flag to the endpoint because the user has not seen or read those notifications yet. The user may never decide to see or read those notifications and so I do not want to make the assumption they will, but I do want to render the UI and the unseen/unread count for them. So, my first request will be without the mark_read or mark_seen flag. If/When the user decides to open the dropdown and see/read the notifications then I would like to mark them as read/seen and I would expect the most up-to-date state of the data to be returned because I explicitly asked the endpoint to update the data. Asking an endpoint to perform an action and not returning the results of that actions is not only confusing but problematic.

This endpoint also falls short when I want to set a single notification to read or seen. If I pass mark_read=<notification_id> to the endpoint it returns me an entire list of recent notifications again (along with the incorrect previous state mentioned above). I don’t actually want an entire list of notifications I just want the one notification I requested to be marked as read.

Personally, I think this endpoint is trying to do way too much and makes too many assumptions. It forces frontend applications to conform to its very restrictive design pattern rather than allowing frontend applications the flexibility to make their own design and state management decisions. This is one of the major reasons the separation of GET from PUT was created. The fact that this endpoint merges these two concepts together and attempts to help manage a frontend application’s state is not only confusing but concerning for me.

Due to the implementation of this endpoint, I would rather not use it for anything other than fetching the most recent list of notifications. Do you have alternative endpoints we can use? I see little documented about notifications. I know that notifications are just a type of feed but they have special behavior associated with them and their data is shape differently. Ideally, we are looking for a way to:

1. Fetch the most recent state for a list of notifications
2. Mark a single notification as read/seen and return the most up-to-date state for that notification
3. Mark an array of notifications as read/seen and return the most up-to-date state of that array of notifications

Alternatively an endpoint that returned the number of unseen/unread notifications would better enable us to use your design pattern. Our UI renders a bell icon with the number of unread recent notifications so we need that data before the user ever interacts with the dropdown, which is why we make the initial request for the notifications without the mark_seen mark_read flags. If we had a way to fetch the number of unread/unseen notifications we could delay the request for recent notifications until the user opened the dropdown, allowing us to set the mark_seen and mark_read flags and leverage your endpoints current behavior.

[shiivan]

We’re having similar integration issues, I wonder if this could also be mitigated by adding a subscription event that pushed the lasted unseen/unread counts of the feed. (This would also allows apps to update their internal state for things like bell icons/badges indicating a user has unread/unseen notifications.)

Then the caller would get a push event of the result of the PUT masquerading as a GET. So something like:

// Realtime notification data format 
  { 
      "data": { 
          "deleted": "array activities", 
          "new": "array activities", 
          "unseen": <count integer>,
          "unread": <count integer>,
          "feed": "the feed id", 
          "app_id": "the app id", 
          "published_at":"time in iso format", 
      }, 
      "channel":"", 
  }

Though I guess this would be a breaking API change since it’s possible developers would expect at least one of “deleted” or “unseen” to be a truthy array and now both could be empty.