0

We are in the process of integrating Stream to power our notifications module. When looking at the usage metrics in the dashboard, we see suspiciously large amount of feed updates: enter image description here

As you can see we have around 9K feed updates per day.

Those daily 9K feed updates don't make sense since right now our backend code does not create any activities.

The only Stream API calls that happen, is when a new user registers we create a new stream for it, of type 'notification', and make this new stream follow a single admin stream which is of type 'flat':

const notifications = client.feed('notifications', userId);
await notifications.follow('user', 'admin');

So for example, if we had today 200 new users who registered, the admin's flat stream will have additional +200 followers.

As of today, we have:

  • 4722 streams of type 'notification'
  • 1 stream of type 'flat'

These are the only interactions we do with Stream's API, and we don't understand what is the source of all those feed updates in the dashboard. (Maybe these follow commands counts as a feed update?)

Yaron Levi
  • 12,535
  • 16
  • 69
  • 118
  • 1
    Hi there, Nick here from Stream. There's likely something going on with your integration. Any chance you can reach out to us at support@getstream.io with some additional details? We'll be sure to get things figured out for you. Thanks! – Nick Parsons Jan 17 '18 at 20:25
  • @NickParsons sending an email right now – Yaron Levi Jan 17 '18 at 20:41

1 Answers1

0

We have something happening very similar. We have a dev app for testing, and suddenly 1K "read feed" operation on notification feed group showed up in the log 1 day ago. Its impossible since we haven't rolled the feature out and in case this is the dev app where we did read the feed at most 10 times manually via postman to our backend to getstream.

The correct ops in the log show client as stream-python-client-2.11.0 which makes sense. The incorrect ops in the log show client as stream-javascript-client-browser-unknown, which does not make sense.

Further the incorrect ops timestamps are all clustered within a short time.

This has not happened since, and has not happened in the production app yet.

zehawk
  • 210
  • 1
  • 10