Reputation: 12742
I'm getting a mysterious intermittent error while hacking on my half-written app:
I20140701-22:39:15.859(1)? Exception in defer callback: Error: failed to copy newResults into _published!
I20140701-22:39:15.859(1)? at Error (<anonymous>)
I20140701-22:39:15.859(1)? at _.extend._publishNewResults (packages/mongo-livedata/oplog_observe_driver.js:767)
I20140701-22:39:15.860(1)? at _.extend._runQuery (packages/mongo-livedata/oplog_observe_driver.js:650)
I20140701-22:39:15.861(1)? at _.extend._runInitialQuery (packages/mongo-livedata/oplog_observe_driver.js:568)
I20140701-22:39:15.861(1)? at OplogObserveDriver (packages/mongo-livedata/oplog_observe_driver.js:164)
I20140701-22:39:15.862(1)? at finishIfNeedToPollQuery (packages/mongo-livedata/oplog_observe_driver.js:16)
I20140701-22:39:15.863(1)? at _.extend.withValue (packages/meteor/dynamics_nodejs.js:56)
I20140701-22:39:15.863(1)? at withoutInvocation (packages/meteor/timers.js:6)
I20140701-22:39:15.864(1)? at Meteor.bindEnvironment.runWithEnvironment (packages/meteor/dynamics_nodejs.js:108)
I haven't yet managed to find a simple way to reproduce it, so I can't really produce a minimal example. It pops up every few minutes, maybe it's related to auto-reloads somehow. Every time it crops up, I have to close all my browser windows and kill the meteor process and restart, so it's a huge pain.
If someone says "ah-hah, here's your problem and how to fix it!" then I will be happy, but really my question is: what kind of strategy can one use for debugging a weird error like this in meteor's guts?
I thought, I know, I'll google! I found this bug: https://github.com/meteor/meteor/issues/2033 which says that it's likely to be a malformed MongoDB query in one of my publish functions. I'll paste them below, but none of them have any of the errors mentioned in that bug, or any errors at all that jump out at me.
Then I thought, I know, I'll just temporarily hack some debugging output into the source file! But it turns out that the file in my project's .meteor directory gets automatically overwritten when meteor starts. So then I tracked down the original source file in ~/.meteor, but it turns out that if I edit this then I get Error: unipackage load failed?
and meteor refuses to start (some sort of checksum or something?).
Then I thought, I know, I'll use a debugger! I managed to get node-inspector running, and even put a breakpoint on the relevant line, but I couldn't figure out how to keep it working through meteor's automatic restarts, and I failed to trigger the bug without restarts. Eventually by screwing around enough (no idea how) I did manage to trigger it at a time when the debugger was claiming to be active. Nothing happened -- the breakpoint didn't do anything, I just got the same log message. I have no idea which piece of this rube goldberg machine is at fault.
So I have an error, it keeps happening on my computer that I have full control over, and yet I find myself helpless to get any more information about it. What do I do?
Publish functions:
# One in coffeescript
Meteor.publish("_psyAssignments", ->
Psy.assignments.find({
$or:
[{_id: @userId},
{group: {$all: [@userId]}}]
}, {
fields: {state: 1, group: 1, present: 1},
}))
# Two in javascript
Meteor.publish("interactions", function () {
return Interactions.find({$or: [{"speaker": this.userId},
{"listener": this.userId,
"listen_act.chosen_object":
{$ne: null}}]});
});
Meteor.publish("censored_interactions", function () {
return Interactions.find({"listener": this.userId,
"listen_act.chosen_object": null},
{fields: {speech_act: 0}});
});
Upvotes: 2
Views: 408
Reputation: 2771
You can copy the mongo-livedata package and put it in your app's packages directory. This will cause meteor to use that package instead of the native one. Then you can add logging or whatever you need into your copy of the package. Just remember to remove it when you are done :)
Upvotes: 1
Reputation: 19544
The first thing to do is to head up to Meteor's GitHub repository and search for the error message. It results with the following line:
So your app has failed the sanity check. Not good.
Reading the surrounding code, as well as tracing the usage of the failing function is a good idea. Often you can spot the possible problem by just reading the code, if not, it will give you the basic understanding of internals necessary to debug them.
Now, if you want to put some debugging code inside that file, there are several options, but one is clearly the easiest. Fork Meteor's repository, point your application's Meteor version to that repo (in smart.json
) and insert debugging code in your repo.
Upvotes: 0
Reputation: 1708
I don't have any idea what is going on with your code, but when I encounter problems debugging Meteor I surround every suspicious code in a "try/catch", as it gives better error messages
(coffeescript):
try
...your code which might generate error...
catch e
console.log e
happy debugging man.
Upvotes: 1