Detect Realm Web SDK Watch() Drops

I’m using the watch() method on the web SDK to keep real time updates shown on my application screen. Sometime, for whatever reason, the watch() stops working. It can be after many hours on Chrome or almost immediately on mobile Safari.

Is there a way to detect a watch() that is no longer connected, so that I can have it reconnect upon this dropping?

1 Like

have you found a solution or know why that happens?

Nope. Abandoned the SDK for a different solution.

the watch() Drops happen mostly on Firefox, any solution to this issue?

i recently create a react app by using realm web template app, the web-js one, and have this error show up every few second when fetching data. i think it is related with your watch() drops issue.

Uncaught (in promise) WatchError: rule with id="62ec12a7614......" no longer exists on mongodb service, closing watch stream
    at WatchStream.feedSse (
    at WatchStream.feedLine (
    at WatchStream.advanceBufferState (
    at WatchStream.feedBuffer (
    at MongoDBCollection.watchImpl (
    at async watchAction (useWatch.js:45:1)

is there a better place to rise the question to find out answers

I am having the same issue. Are there any solutions for detecting dropped watch()'s?

they created this sandbox

1 Like

i use chrome, it is the same

Li_Li3, thank you, this is heroic.

I fixed my issue by moving the rules from the default to individual collection, i am not sure why, but the watch error disappeared.

1 Like

Made a visual guide to help people with a similar issue, Li_Li3 is right- although I wish I saw their comment before doing my own deductions.

1 Like

Then set granular permissions.

I’m having the same issue using the web sdk.

The issue won’t occur, if I use the example app provided here:

However, if I use that very same example app without any changes but using my own atlas app id, the errors show up again.
So it’s definitely connected to some backend configuration. I just don’t know which one. Will create a new test app and try to apply my settings one by one…

Does anyone have an idea what the problem might be?
It’s not the rules issue as described above for me as I’ve already deleted all default roles for testing.

@Daniel_Weiss difficult to tell, without more information, I too used the code sandbox example and it worked with a test app when I was first problem solving this issue.

I’ll provide some more information on my set-up , my code snippet from my app, and what rules looks like on my end. This was frustrating for me, so I hope this will help you solve it faster.

  1. I’ve deleted the default permissions, and then set manual permissions on each of my collections
  2. I’m on “realm-web”: “^2.0.0”,
  3. My Snippet
export const watchCollection = async () => {
  const processing = app.currentUser
  if (!processing) {
 for await (const change of changeStream) {
    switch (change.operationType) {
      case 'insert': {
      case 'update': {
        const {fullDocument} = change;
// awesome things
       case 'replace': {
       const { documentKey, fullDocument } = change;
       case 'delete': {
         const { documentKey } = change;
  return changeStream;

/*Then in my react app*/

  useEffect(() => {
  }, []);
  1. A screen shot of my rules in the App Services UI

Thank you very much for your help, @Paul_Vu.

I finally figured it out. Having DeviceSync enabled, I assumed that those roles would take precedence and while I haven’t tested for that - I still think they do. However, the error occurs when there are no rules (not DeviceSync permissions but “normal rules”) setup. Once I did that and - importantly - no default rules as mentioned above, it did work.

So, to recap, my setup is as follows:

  • Rules for each collection → no default roles.
  • The very same rules adapted as DeviceSync permissions. Here default roles are ok.
  • DeviceSync is enabled

I connect to the backend via both the Flutter SDK and the Web SDK. It both works now.
Maybe this helps someone else struggling with the same problem.

1 Like

Glad you got it resolved, good to know about the no rules part!