We still have 1 collection where we use pub/sub + mini-mongo and allow client code to do updates via allow/deny.
How can we catch errors on the server?
When the client code does <collection>.update(), it fires an RPC to the server where the endpoint calls our allow/deny routines to validate. Finally, the endpoint calls Mongo update. Our problem, the update can fail (rarely) it throws. What we want is to catch this exception, log it, and possibly fix it, and re-throw if we can’t fix it.
Any suggestions about how we can hook or monkey patch the server endpoint?
Thanks for your kind reply. My question was possibly unclear.
The update is initiated from the client as you noted. We want to catch the exception when it is thrown on the server… before replying to the client.
Long term plan is to switch, but this particular collection has some non-trivial code that needs to be redone first b/c it assumes the synchronous behavior of mini-mongo.
I don’t get the problem then. Minimongo stays “sync” (through simulations) even in methods. Maybe you could post some example code to present the problem?
Thank you both for trying to understand our problem. Sorry for the delay.
I am not keen to explain exactly why we are not ready to switch to RPC for updates and away from mini-mongo. Simply understand that we pub/sub and update.
With that starting point, if the server throws, the client can NOT get an error message and the server logs a bunch of useless noise in the console. What happens is that mini-mongo will get an update from the server and “roll back” the update that failed. But the only error message is the generic “Internal server error [500]”.
We are not trying to give the client a smarter error message. We are hoping to “fix” (if possible) the problem on the server. We need a way to catch the exception on the server.
Errors are being logged by the Galaxy APM or MontiAPM. So any error should be logged by these APMs.
Custom error handlers:
// Meteor debug handler
const originalMeteorDebug = Meteor._debug;
Meteor._debug = function _debug(message, stack) {
// do anything about the debug message and stack here
// call the original debug handler here
return originalMeteorDebug.apply(this, [message, stack, arguments]);
};
rjdavid, We can see the errors in APM and in the general log. We have no problem re logging. It is a question about trying to catch and handle the error.
Meteor._debug is a great tip that opens up some ideas we can chase down. Thanks!
Max, nothing tricky. This is a very typical code pattern with nothing surprising. We can wonder why the framework doesn’t give us an easy hook like beforeUpdate/afterUpdate (like allow/deny), but let us also acknowledge, using client-side update is a deprecated pattern.
Client user code calls update.
Meteor framework makes RPC call to update
The mongo call throws
The Meteor framework returns generic “internal error” to client
We just want a sanctioned way to hook or monkey patch the meteor framework’s rpc call.
We know which error and why the error is thrown. We also think we know how to fix the error. Thus we need a hook so we can run some code.
The RPC that gets called is (collection)/update.
One possibility is to patch that endpoint… (how?) Or, perhaps folks know of another way to hook the client-side update when it reaches the server.
You can patch the method that Meteor creates for that collection just on the server, or the actual collection.update() function on the server
The quick and dirty way would be to patch it on the Meter.methods() function and look for when the specific function is being called, or maybe go into deep apis and patch the method function that is registered. IIRC there’s a method hooks package for this.
Or maybe you can do Meteor.isClient/Meteor isServer in the isomorphic code to outline some specific error handling as well
