Meteor publication send custom sanitized error to client in publication - meteor

I am not sure if I am just doing something wrong or if this is actually not working. I want to display the original publication error on the client, in case I catched one:
Meteor.publish('somePub', function (args) {
const self = this
try {
// ... publication logic
catch (pubErr) {
self.error(pubErr)
}
})
On the client I am "catching" this error via the onStop callback:
Meteor.subscribe('somePub', args, {
onStop: function (e) {
// display e to user
}
})
However, while on the server the pubErr is a Meteor.Error and according to the documentation it should be sent to the client, the client just receives a generic sanitized error message:
on the server
{
stack: "useful stack of actual method calls",
error: "somePub.failed",
reason: "somePub.invalidArguments",
details: { arg: undefined }
}
on the client
{
stack: "long list of ddp-message calls",
isClientSafe: true,
error: 500,
reason: "Internal server error",
details: undefined,
message: "Internal server error [500]",
errorType: "Meteor.Error"
}
Note: I also tried to add the error to itself as sanitizedError field, as in the documentation mentioned, but no success either.
Am I missing something here?

Actually I found the answer to the issue after being pointed into the right direction.
The example code works fine on a new project, so I checked why not in my project and I found, that I did not surround the arguments validation using SimpleSchema by the try/catch (unfortunately my question was poorly designed as it missed this important fact, mainly because I abstracted away the schema validation from the publication creation):
Meteor.publish('somePub', function (args) {
pubSchema.validate(args) // throws on fail
const self = this
try {
// ... publication logic
catch (pubErr) {
self.error(pubErr)
}
})
So I thought this could not be the issue's source but here is the thing: Simple Schema is not a pure Meteor package but a NPM package and won't throw a Meteor.Error but a custom instance of Error, that actually has the same attributes (error, errorType, details) like a Meteor.Error, see this part of the source code of a validation context.
So in order to pass the correct information of a SimpleSchema validation error to the client you should
wrap it in a try/catch
add the isClientSafe flag to it
alternatively convert it to a Meteor.Error
Attach a custom Meteor.Error as sanitizedError property to it

Related

How to access backend errors with Redux createAsyncThunk

I am not sure how I am supposed to get the errors that come from the backend when a POST request is sent to the backend. If I use plain axios calls, I can simply get the errors from the response object in the catch block with:
error.response.data.errors
But when using Redux and using createAsyncThunk method, on a 400 status code from the server, a rejected action is dispatched and the error object I get is a generic one like so:
{
message: "Request failed with status code 400"
name: "Error"
stack: "Error: Request failed with status code 400\n...."
}
How can I get the server errors, just like using axios?
You can make use of the rejectWithValue function from redux-toolkit to include the server error as the payload property of your rejected action.
It would be something like this (untested code because I’m on my phone)
const myAction = createAsyncThunk(
‘actionName’,
async ( arg, {rejectWithValue} ) => {
try {
const res = await axios.post(…);
return res.data;
} catch (error) {
return rejectWithValue( error.response.data.errors );
}
});
I think what you can do is add an additional check for the errors and also wrap the axios post request with a try catch block.
Note : In your case the request is failing so I guess there must be some error with the way you are making a request.

Errors thrown on Meteor server methods dont log original stack trace

Since upgrading to meteor 1.8.0.2 from 1.6.x I've noticed that any method call that results in an error is printed on the server console as:
Exception while invoking method 'login' [object Object]
Exception while invoking method 'customMethodByMe' [object Object]
This happens both on development on my mac and deployed on Galaxy.
Before, the whole stack trace was printed, but this Object object logging doesnt help me figure out the actual problem. My solution so far has been to wrap method implementation in a try catch statement that logs the original exception and rethrows it for the client to know.
Meteor.methods({
'customMethodByMe'() {
try {
return customMethodByMeImpl();
} catch (e) {
console.log(e)
throw e;
}
}
});
In this case, since the error is on the login method which is in a package, I cannot update it to print the real problem. On the client, all I get on any error is that there was a 500 error on the server, so no root cause either.
{"isClientSafe":true,"error":500,"reason":"Internal server error","message":"Internal server error [500]","errorType":"Meteor.Error"}
Any ideas on how to temporarly solve this? I've been searching for a server level error handler but so far have found nothing.
thanks
I did not get to experience this directly, but when I need to print an object, I usually use JSON.stringfy.
Meteor.methods({
'customMethodByMe'() {
try {
return customMethodByMeImpl();
} catch (e) {
console.log(JSON.stringify(e));
throw e;
}
}
});
This should resolve so that you can at least read the error log.

In-Context Checkout: No response handler found for post message response error

I use Advanced In-Context Checkout integration.
I do AJAX and utilize these functions, just as their docs explain it:
paypal.checkout.setup()
paypal.checkout.initXO()
paypal.checkout.startFlow()
paypal.checkout.closeFlow()
And I constantly get this annoying error after Execute the payment step. They didn't bother to explain it anywhere is their API docs. It is just missing.
new Error("No response handler found for post message response "+t.name+" in "+window.location.href);
What does the error mean? What kind of response handler for post message response is expected? How to provide it?
My client side code is as simple as the following:
onCheckoutBtnClick(ev) {
paypal.checkout.initXO();
$.post('/checkout', {
user: JSON.stringify(this.props.user),
data: JSON.stringify(this.props.WCs),
})
.done(res => {
paypal.checkout.startFlow(res.approval_url);
})
.fail(err => {
paypal.checkout.closeFlow();
});
},
And server side is as follows:
router.post('/checkout', (req, res, next) => {
var payment_json = {
// huge config to create a payment
// the pivotal value is "return_url"
redirect_urls: {
"return_url": "http://example.com:3000/complete_payment",
"cancel_url": "http://example.com:3000/cancel_payment"
},
}
});
And return_url code
router.get('/complete_payment', (req, res, next) => {
paypal.payment.execute(req.query.paymentId, execute_payment_json, function (err, payment) {
// After this step the error in thrown on the client
res.redirect('http://example.com:3000/show_complete_page_to_buyer');
})
})
It seems like this is a Sandbox problem only. See this error all the time in Sandbox and newer seen it in production mode.
I have mailed the Paypal developer complaining on the many difference between sandbox and production.
The sandbox has issues for me also that often correct themselves on a refresh. Using the Chrome developers tools (Ctrl-Shift-I) and reviewing the console log I see this stack trace:
types.js:19 Uncaught Error: No handler found for post message ack for message: postrobot_method from http://localhost:50834 in https://www.sandbox.paypal.com/webapps/hermes/button
at Object._RECEIVE_MESSAGE_TYPE.(anonymous function) [as postrobot_message_ack] (https://www.paypalobjects.com/api/checkout.js:2514:33)
at receiveMessage (https://www.paypalobjects.com/api/checkout.js:2465:77)
at messageListener (https://www.paypalobjects.com/api/checkout.js:2486:13)
I've also observed the error can be triggered by unhandled javascript exceptions elsewhere in my code.
I solved wrapping the button init function in $(window).load()

Breeze query error, even though results returned

Breeze is calling the "fail()" function, even though the data seems to be returned from the odata service (as well as being in the error object). There are 5 "transactions" returned from the ODATA service (as seen in Chrome developer tools) as well as in the "data" property of the error object being passed to the fail function.
Calling code looks like this:
function getTransactions() {
var query = breeze.EntityQuery.from("Transactions")
.take(5);
return entityManager.executeQuery(query,
function(data) {
log("transaction Query success!");
var transactions = data.results;
},
function(err) {
log("Query failed:" + err.message);
});
}
I am at a loss as to what is wrong that is causing the "fail()."
There IS a Transaction constructor defined, code below:
function registerTransactions(metadataStore) {
metadataStore.registerEntityTypeCtor('Transaction', Transaction);
// constructor -- empty
function Transaction() { };
Object.defineProperty(Transaction.prototype, 'itemCount', {
get: function () {
return 0;
}
});
}
Note the url for the odata resource is "Transactions" but the entity is Transaction. What are the reasons why the "Fail() function would be called?
Error.message = "; " which isn't helping much.
I believe I am on the latest Breeze 1.4.11 and datajs 1.1.2
After much research, I found the problem was another funcky CORS setting on the service side. I was able to figure it out by going directly to dataJS against the same service, and getting a more informative error message.
What you MUST do on the service side is something like this:
var cors = new EnableCorsAttribute("*", "*", "*", "DataServiceVersion, MaxDataServiceVersion");
The last parameter has to with the service sending the OData version in the header and thereby allowing the client to determine if it can handle the specified version of OData.
If anyone knows more details about this, feel free to comment.

In Meteor, what is difference between this.error and throw new Meteor.Error in Meteor.publish?

In Meteor.publish, what is a difference between using this.error and simply throwing an Meteor.Error?
this.error is only available inside the publish method. Per the docs:
Stops this client's subscription, triggering a call on the client to the onError callback passed to Meteor.subscribe, if any. If error is not a Meteor.Error, it will be mapped to Meteor.Error(500, "Internal server error").
Throwing a Meteor.Error would not stop the client's subscription, it would just terminate execution and raise the exception. So if you want to ensure Meteor will clean up after you and allow you to handle the error on the client when something unexpected happens, it's recommended to use this.error rather than throwing your own inside the publish method.
It seems they are the same. In the source code:
try {
var res = self._handler.apply(self, EJSON.clone(self._params));
} catch (e) {
self.error(e);
return;
}
So if there is an exception thrown, error is called anyway. error also stops the subscription.

Resources