Say I do a method call to my meteor app’s server, which then calls a method on another server:
Meteor.methods({
myMethod: function (param) {
if (!param) {
throw new Meteor.Error('no-param', 'You need to pass a param'); // this works fine, obviously
}
const connection = DDP.connect('https://some.other.meteor.server');
connection.call('anotherMethod', param, function (error, result) {
if (error) {
console.log(error); // shows on my app's server, as expected
// because this is another async call, the method containing it has already returned
// how can I get this error back to the client?
throw new Meteor.Error(error); // throws it on my app's server, but the method has already returned with no error, so I don't see get to see the error back on the client
}
}
}
})
How can I get that error that occurred on the remote server back from my own server to my client?
(Note: None of the behaviour above is unexpected, it’s just a question of how you go about doing it.)
Just added a comment to the above code. Throwing (or rethrowing) an error after the method call to the remote server has returned won’t result in the error getting sent back to the client, as the containing method has already returned with no error.
If you do not pass a callback on the server, the method invocation will block until the method is complete. It will eventually return the return value of the method, or it will throw an exception if the method threw an exception.
I need the callback because, if there is no error, I use the result from the remote server to make changes to data on my server.
(That bit about blocking when you don’t pass a callback on the server - does that apply to calls on connections to remote servers as well? I’m not sure I’d want it blocking in that case!)
Yeah, I was wondering about that. I’m just not quite sure where the async and await would go when dealing with an async method call from a server within an async method call from a browser.
I would convert them into documents that are stored in a collection and subscribe on the client to it. Beware that this can slow down things a lot if you log a lot but if it is a narrow space of actions and the error log is important to the client then I would do it this way.
Yeah, I thought about doing that but surely there’s a neater way. The errors aren’t something I need to persist in the db; they just need to be reported to the end user. I guess a cron job could just purge that collection every so often …