Strange phenomenon: Subsequent methods or subs won't succeed

[waldgeist]

@zodern

It enables the inspector in the running Node process

Wow, that’s amazing! Another thing where mup shines as a real gem.

@zodern

A number of packages wrap or overwrite the functions involved in processing messages

Are there any “known suspects” - i.e. frequently-used packages like (maybe) simpleschema - that come to your mind?

[peterfkruger]

@zodern

Assuming the method or publication works correctly (it returns, and if it returns a promise, the promise is eventually resolved)

I’ve tested the scenario today where a Promise is returned in a method, yet (intentionally) never fulfilled.

It causes the effect, as was reasonably expected, that the method’s callback is never called on the client. But that was all; no other method was affected, the server remained fully operable.

In contrast, when this bug hits a server, once it happens, the server becomes seemingly unresponsive for all clients and with respect to any method (and possibly publications), until restarted. The DDP connection to the clients, however, remains intact.

[waldgeist]

@peterfkruger

unresponsive for all clients and with respect to any method (and possibly publications)

In my case, the first method / sub of a user session actually succeeds, but all subsequent methods / subs in the same session fail (it might as well be two or three that work; I haven’t checked this 100%).

If you reload the browser (or use the same code inside a web view on another mobile device), you get one more successful try, and then methods and subs fail again.

But yes, all users are affected. Things only get back to normal once you restart the server.

[peterfkruger]

There are right now two different apps, one of which is yours, that are currently hit by this bug, and there are of course countless other apps that aren’t affected. Maybe if we managed to find out what distinguishes these two apps from all the unaffected ones, we’d be getting closer to pinpoint the bug.

[rjdavid]

@waldgeist

What’s the reason why methods block by default? Is this because Meteor wants to assure that subsequent operations run in order? Because otherwise I’d say that blocking is only needed if methods rely upon each other, so an explicit block might also make sense.

That is the only reason I can think of. In our team, we consider all client method calls are async. So we explicitly override the call function and execute this.unblock() for all method calls

[waldgeist]

Maybe if we managed to find out what distinguishes these two apps from all the unaffected ones, we’d be getting closer to pinpoint the bug.

Happy to share more details, like the packages I am using.

[peterfkruger]

I’ll PM you later today.

[waldgeist]

Awesome. Keep in mind that I’m in the CET time-zone, so there might be a delay in my response.

[james]

Have you taken a look under the hood and checked the websocket messages? This is what happened to me:

1. The method message is sent to the server
2. The result message is sent to the client from the server
3. The updated message is missing in action, it never ends up happening

When this happened it’s because I accidentally “blocked” the DDP connection inside a method or subscription. For example, let’s say I make a method call that returns after waiting 100 seconds. If I call that method from the client, I am not going to get the updated message for 100 seconds and tracker will not recompute even if there are other messages (ui will be frozen) while waiting on the response.

[peterfkruger]

Does that scenario have the potential to block method calls and tracker recomputations for other users too? Or would that block stuff for the client only that called that long running method?

[james]

Methods and subs run in a fiber that is coupled with a specific connection, so it would only affect the client that caused the long running method/subscription. I am not sure how one could create a globally blocking process other than doing synchronous plain javascript code such as fs.readFileSync.

Interestingly, I am starting to see some weird behavior that isn’t what I’ve seen before: The moment I render a FlexibleWidthXYPlot from react-vis, my ready variable from my useTracker always returns false. Could be related.

[peterfkruger]

Consequently, for a phenomenon in certain apps where seemingly all users are affected, it may be enough to have a single long (e.g. endlessly long) method/subscription that sooner or later each client invokes, right?

[waldgeist]

I think this is unlikely in my case. The problem appears on the very first load of our app where I am pretty sure that such a method is not being called. And even if so, how would you explain that the problem completely goes away once I restart the server? From that time on, all user tasks work as normal, whereas before only the first method succeeds.

[filipenevola]

Hi @waldgeist, as this problem was also reported on GitHub I preferred to reply there.

TL;DR

I believe this is a problem in one of your publications or methods causing this problem as a side effect. The way to investigate the root cause was already well explored in the replies above and also the tools to find it but in my reply on GitHub I tried to provide a way that I was always able to avoid these problems on my code affecting different parts of my project (unblocking everything).

---

I believe it was more a question than a report of a bug in Meteor.

If you agree we can follow the discussion here and close the issue.

[waldgeist]

Hi @filipenevola, thanks for the feedback.

I checked all my methods in the meantime and could not find any cases where the method would not return. But to be sure, I added this.unblock() to all of them (except those that delete data, but they are simple).

One problem I am facing here: There might be other methods in community packages that do not unblock. IIRC, I saw one in the Sign in with Apple package I am using.

Didn’t know there are packages that enable this.unblock() for publications. That’s great. Unfortunately, meteor-unblock is not maintained anymore. Any chance to get this into the Meteor standard?

Besides: Yes, feel free to close the issue. I will keep an eye on my production server and re-open it should the problem not be resolved with the unblocks.

[filipenevola]

Hi @waldgeist, are you having issues with this package GitHub - lamhieu-vk/meteor-unblock: A utils to unblock subscriptions, a this.unblock inside publications in Meteor version 1.7 or newer?

[afrokick]

@filipenevola what you think about Provide this.unblock in publish context · Issue #11 · meteor/meteor-feature-requests · GitHub ? pub.unblock seems like a core feature.

[waldgeist]

No. I am just skeptic about packages that have been abandoned.

[peterfkruger]

I don’t understand why publications need this.unblock() in the first place.

The concept of methods of the same user to be executed in the order of invocation is understandable, although still a little questionable. I can’t comprehend how that translates to publications though, as there is nothing akin to an invocation order there, publications get active reactively, so what do we exactly unblock there?

[afrokick]

AFAIK client must receive ‘ready’ message for publication from server to unblock next ddp message. The server send ‘ready’ message after initial docs from pub was sent to the client.

maybe i wrong?