How to debug EJSON problems?


#1

I’ve added a property named creator to one of my my model objects, which contains some information about the user that created the object:

creator: {
_id: ...
username: ...
avatar: ...
}

All other properties of the model object remained the same.

After this change, I get a weird error from the server when calling Meteor.call(). In the client console, it just says:

Received error from server:  Parse error

but there is no error message on the server console. I double-checked the return values of my EJSON methods, but everything looks fine. The error occurs right after the client has called Meteor.call().

Any ideas what may cause such an error and how to debug this?


#2

I think I’ve narrowed down the problem. In my object constructor, there was a call to Meteor.user(). This call fails silently if EJSON builds the object and causes the parser error. I cannot even put a log message after the Meteor.user() call. It seems as if Meteor.user() may not be called while constructing objects based on their EJSON representation.

If I wrap this call in a try-catch-handler, I get this error message:

Error: Meteor code must always run within a Fiber. Try wrapping callbacks that you pass to non-Meteor libraries with Meteor.bindEnvironment.

#4

Hi @waldgeist, did you find a way to get around with this problem? I’m getting the same error message.

The object I’m passing in to Meteor method is an instance of an astronomy class. Did you also use that library?

Any thoughts from the community?


#5

Update:

I tried to use a dummy method to replace the original one for debugging, and then switch back (so technically nothing is changed). The error is gone.

I found this is a strange bug. I have encountered the same bug roughly a month ago, and the same magic happened at that time. So I’m not able to reproduce the issue…


#6

I did not find a solution, but a workaround. I am now wrapping the call to Metoer.userId() in a try-catch block:

  try {
    userId = Meteor.userId();
  } catch (e) {}

It’s not optimal, because I cannot get the user information in this case, but it works for me, because I typically pass in the user info as a parameter to the constructur directly, so the Meteor.userId() call inside the constructor was rather meant as a convenience fall-back for the caller of the constructor.

BTW: I also filed a bug report in the Meteor repository. David Greenspan confirmed that a call to Meteor.userId() is not possible when an EJSON object is passed:

I recommended to state this in the docs somewhere, because it is valuable information and quite hard to debug.


#7

Yay I noticed this issue on Github. Thanks for bringing this up! It will be nice if someone later could make an error reproduction repo.