I am interested in the best practice for handling errors in the Google Action SYNC handler.
I see in the docs that I can return an errorCode in the SYNC response, however, none of the documented error codes seem to be compatible with the SYNC handler, only QUERY, EXECUTE, etc.
I see that the SYNC response must contain a userAgentId or the Action service deems it an invalid response, however, what happens when I am unable to authenticate the user and I am unable to determine and ID for them?
In that case, should I simply provide an empty string for that property?
Should I just response with an empty object {} in the response when I encounter an error?
Any info is helpful, thanks.
Of all the listed error codes, not all of them may make sense but some like relinkRequired could be useful.
More specifically for you, in the case that the authentication process fails that error should come from the OAuth link. Your account linking, when presented with an incorrect user, should fail at that point and not proceed with sending a SYNC response.
Related
This is sort of an extension of this question here. I have a policy that calls a REST API. The API returns an error message and this message needs to be localized.
One way is to of course get the API to return a localized message, but is there a way for the CustomPolicy itself to localize the error code? According to the CustomPolicy Docs, a REST API can send an error code along with the Conflict error code. Our thinking was to use this error code as a key and select a localized message (from the messageValue enum mentioned in the answer in the link).
However, we can't seem to capture/handle the error data returned by the API. The Policy seems to handle error codes by itself and we would like to know if it is possible to inject localized exception/error messages from the policy itself.
Thanks in advance!
Edit: A little more information about the setup. We have a TechnicalProfile that has a DisplayWidget and a ValidationTechnicalProfile. The DisplayWidget is used for entering & verifying the user's phone/email and the ValidationTechnicalProfile makes the final call to the RestAPI with all the user's information to register him/her. This RestAPI call output is what we want to localize.
The suggestion in the linked SO question, from what I understand, is that we integrate another DisplayClaim (that references an enum) in the DisplayWidget, and depending on the ErrorCode returned by the call, change it to display the appropriate code. However, as per my understanding, this would also require editing the API to return only 200 along with a code. This code would indicate the true nature of the result - success or a code for one of the enums to be displayed.
Our aim therefore is to check if there is a way to follow the Policy's flow (disrupt the SignUp/SignIn process) but at the same time localize the API's displayed response.
We managed to find a workaround to this, so I'm posting this here for anyone else who might be interested in this.
Our restriction for localizations was the fact that used Phrase to manage our translations and wanted the CustomPolicy specific translations all in one place. Our CD workflow was as follows:
PolicyCommit -> Build Variable Replacement through PS -> Release Variable Replacement and localized strings replacement through PS & Policy Uploads
Barring the policy from localizing the APIs response, we had the following options to achieve this:
Sending the language to the API and having the API return the appropriate error message
in the appropriate language. We were reluctant to follow this because of a multitude of reasons, but mostly because we would also have to handle different regions, etc. in the API - something the policy does by itself.
We actually had only one API that we called, and also only two error messages that were used. Hence we created an enum with the two error messages that would be localized. We then used a chain of InputClaimsTransformations that did the following:
Repeat Steps 1 through 3 for all the errors
1. CreateStringClaim (Create ClaimTypes for each of the error codes, holding the index of the error code in the enum)
2. GetMappedValueFromLocalizedCollection (Make the localized enum choose and hold the value of the required error code)
3. AddItemToStringCollection (Add the localized error from the enum to a StringCollection)
4. GenerateJson (Add the error codes StringCollection to the JSON payload to be sent to the API)
This way, the policy performed the localization for all the errors and we sent them along with the request to the API. The API, when an error occurred, picked one of the error messages from the policy and sent it back. This method was for us, because of our CD structure and Phrase integration, much easier than actually having the translations in a file hosted on the cloud to be accessed by the API.
Hope this helps someone; I can also add code in case someone needs it :)
I have created a route that via a splitter does multiple lookups, aggregates the responses and returns the list of objects.
I use a remote proxy to invoke the route.
Given that there are multiple branches on the route it is possible that some will succeed and some will fail. How can I get all the returned results but also a list of failures, with reasons for failures, from the remote proxy?
I can think of 3 options, but hope there is something cleaner
Use a header structure that is passed in with remote proxy call to collect errors
Wrap the return value of the remote proxy in structure that contains results and errors
Route errors to some error endpoint (not sure how to correlate with my request though)
Are there any other options?
I would go with option 3. Route all the errors to a generic error endpoint where you log the errors and return some default response. That way you can refer to that generic error endpoint from all your branches ensuring they will all react the same way whenever they encounter an error.
You should be able to get exception details in Aggregation strategy class and accordingly take action.
It depends on what you want to achieve from overall design. As a general practice, if you want consumer of your remote practice to fail on errors, it should get the exception details immediately. If your remote proxy is a REST Endpoint, it can return with 500 error. And similar strategy can be followed for other protocols.
What's the best way to add email notifications for CakePHP crashes? I want to be emailed with a stacktrace whenever a fatal error occurs, so that I can know immediately instead of checking the logs.
I looked at overriding AppController::appError(); but I don't want to replace all of the exception handling.
Check this out, it is to long to paste here.
https://github.com/CakeDC/utils/blob/develop/Error/EmailErrorHandler.php
It is a customized error handler for CakePHP. You need to configure CakePHP to use that error handler class. My pull request to the core was rejected that introduced an Event in the handleError() method... An event there would make it really easy to handle use cases like this.
I'm wondering how people typically do error handling with backbone.js. It would be nice for something to popup everytime I call model.save (which in turn calls Backbone.sync). The thing is, how does backbone.js know when an error or a success has occurred on the server? I understand it would know if there was a 500 server error or something like that (which jquery knows about since Backbone.sync calls jQuery.ajax) - but I want to be able to pass messages and other codes so I can give more meaningful error messages to the user.
I have one idea and would love some feedback. The idea is to override Backbone.sync. The new sync gets a response from the server, which must be in a particular format. This format would be something like:
ServerResponseObject:
> ResponseCode
> Message
> Model
Nothing fancy, but basically, instead of just returning the plain model, it is wrapped up with a ResponseCode and Message which can be shown to the user.
Is this the normal way to do it? Any other approach that is better?
Thanks!
In my ears this sounds a bit on the complex side, at least to start with. Backbone.sync will already report errors that you can catch in your models .save() method:
this.mymodel.save(/* ... */, {success: function(model, result, xhr)...,
error: function(model, xhr, options)...}
(docs).
If your serverside follows HTTP specs well, the error code is already provided (500 - server error, 404 - model not found, you know..), and even if the server sends an error code it can still send content (perfect for your message). So you basically already have all parameters built in to the HTTP protocol itself. In my experience you get to write less code if you work with the protocol instead of building new layers on top of it.
In your errorcallback above, you probably have good possibilities to call the rest of your system and post an error to some application message bus or similar (via Backbones own event mechanism or some dedicated library).
We switched to sending back the standard format JSend a while back. It's basically just a JSON wrapper around the response that has provisions for messages and error codes to come back in addition to the data you expect.
The main reason we had to do it was because we had services which were responding with 400 errors when it was really not the appropriate thing. The client didn't have malformed syntax or any protocol level errors at all, there was just some problem with something where we needed a more nuanced response and that gave it to us. After we did that everybody ended up much happier on both the client and server sides.
I'm getting a strange error in my newly deployed application in appengine. In the error log it tells me that PageRank, TwitterBot and a couple of others. I would guess this is due to these try to get data using ajax or another async service resulting in "same origin policy"-problem.
My question is does anyone know what these bots are trying to get? For example if pagerank (google page rank I would guess) can't get any info about my application would this effect my page rank. And anyone know what the twitterbot does? And if there is away to handle to provide a proper response?
Most likely, your RequestHandlers (I'm assuming you're using python with webapp from the tags on your earlier questions) aren't implementing a method for whichever request method the bots are using. I'd guess they're HEAD requests, and you have no head() methods defined.