I'm facing a strange issue with direction service in azure maps.
When I make this request with car in travel mode :
https://atlas.microsoft.com/route/directions/json?subscription-key={my-api-key}&api-version=1.0&query=48.81532,2.34954:52.31281,4.94103&language=fr-FR&computeTravelTimeFor=all&travelMode=car&arriveAt=2018-10-30T09:50:00-00:00
I got a good response with a proper json, but I make the same request with bicycle travel mode :
https://atlas.microsoft.com/route/directions/json?subscription-key={my-api-key}&api-version=1.0&query=48.81532,2.34954:52.31281,4.94103&language=fr-FR&computeTravelTimeFor=all&travelMode=bicycle&arriveAt=2018-10-30T09:50:00-00:00
I get the following error :
{ "error": {
"code": "400 BadRequest",
"message": "Bad request: one or more parameters were incorrectly specified or are mutually exclusive." } }
I can't figure out what makes this error
I changed the arriveAt time to 2018-10-31T09:50:00-00:00 and it works. Perhaps biking takes so long that it's impossible to arrive at the destination by the specified arriveAt time.
Related
We try to do acknowledge google play purchase on the server-side through purchases.products.acknowledge with golang
However, the following errors come up sometime
googleapi: Error 409: The operation could not be performed since the object was
already in the process of being updated., concurrentUpdate
googleapi: Error 400: The purchase is not in a valid state to perform the desired operation
Is there anything am I missing? or how to solve those errors?
Per google support
For error 400, the purchaseState must be Purchased or 0 before you can acknowledge the purchase. For more information, please refer to this page: https://developer.android.com/google/play/billing/integrate#process
Error 400 can also mean that you already acknowledged the purchase.
For error 409, this means you are acknowledging the purchase multiple times concurrently. Unfortunately, we don't provide support for API concurrency issues.
Currently having this exactly issue, did you manage to resolve it in the end.
Acknowledgement Request Response: {
error: {
code: 409,
message: 'The operation could not be performed since the object was already in the process of being updated.',
errors: [ [Object] ]
}
}
I'm only sending it once, after i have validated and added to my database. I'm not sure why its happening.
EDIT:
I had a theory my code was executing to fast and maybe the order was still pending, so i added a 10 second gap between getting purchase token and then trying to acknowledge once again. Im now getting the following.
Acknowledgement Request Response: {
error: {
code: 400,
message: 'The purchase is not in a valid state to perform the desired operation.',
errors: [ [Object] ]
}
}
However at this time in Google Play Console, the state is Chargeable, meaning it just needs to be acknowledged.
I have an application that reads users mail messages. I made the same call multiple times in a row. The middle attempt i received an error indicated that the requested user was invalid. I know this to not be true since i had requests before and after this request pass with the same parameters.
{"error": {"code": "ErrorInvalidUser", "message": "The requested user 'scrubbed' is invalid.", "innerError": {"date": "2020-10-05T14:42:17", "request-id": "30ede436-594b-4146-b06f-42ceff3201db", "client-request-id": "30ede436-594b-4146-b06f-42ceff3201db"}}}
I am wondering what conditions can cause this error. Would an expired oauth token cause this error. Or does this error really reflect that this user no longer exists? (in this case, that would not be an accurate error message).
I did check this page to see if this error is mentioned, but nothing is listed:
https://learn.microsoft.com/en-us/graph/errors
While implementing REST APIs, validation is done of the request body received by the server.
What if some extra information which is not required (as well as not specified in REST API spec) comes in the form of JSON attributes and it's found during validation. In this case, what should the server do? Ignore extra data and send a response as a success or error response is preferred usually?
If error response suits best when HTTP error status most compatible in this case?
An example is given below:
{
"data": {
"type": "user",
"attributes": {
"firstName": "Kazi Mahbubur",
"lastName": "Rahman",
"age": 30,
"x": "x",
"y": "y",
"z": "z",
}
}
}
In above request body (JSON type), the x, y, z attributes are not required according to REST API spec.
In this case, what should the server do? Ignore extra data and send a response as a success or error response is preferred usually?
You'll want to look into prior art in XML, especially concepts like must-ignore.
The short version: you need to think about what you want to have happen when a version 1 client tries to talk to a version 2 server, or when a version 2 client tries to talk to a version 1 server (aka forward and backward compatibility).
The world wide web, for example, has been going for thirty years now; it does that, to a large degree, because the standards (HTTP, HTML, URI) have been constrained to evolve in ways that support compatibility.
For example, take a quick read at what Roy Fielding wrote about Host
One of the worst mistakes in the early HTTP design was the decision not to send the complete URI that is the target of a request message....
Now consider: Fielding published this passage 20 years ago, and we still haven't changed the way it works. HTTP messages, for the most part, have the same semantics that they did in 1996 when RFC 1945 was released.
If error response suits best when HTTP error status most compatible in this case?
If you decide that an unrecognized schema should not be permitted, then you'll want to choose meta data that accurately reflects that.
RFC 4918, which defines the semantics for 422 Unprocessable Entity, includes a pretty good decision tree
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
For example such code:
os.Stderr.WriteString(rec.(string))
But this will not show as an error:
I know that I can panic after logging and catch it on API Gateway (against sending stacktrace to the client) - no other ways? Documentation is not mention anything like that.
It seems not possible. I assume, you're looking at the metrics in Amazon CloudWatch
AWS Lambda automatically monitors functions on your behalf, reporting
metrics through Amazon CloudWatch. These metrics include total
invocations, errors, duration, throttles, DLQ errors and Iterator age
for stream-based invocations.
https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-metrics.html
Now, let's see how do they define errors
Metric "Errors" measures the number of invocations that failed due to errors in the
function (response code 4XX).
So, if you want to see the errors on that graph, you have to respond with the proper codes. If you're concerned about exposing the error stacktrace, here is a good read Error handling with API Gateway and Go Lambda functions. The basic idea there is about creating a custom lambdaError type, meant to be used by a Lambda handler function to wrap errors before returning them. This custom error message
{
"code": "TASK_NOT_FOUND",
"public_message": "Task not found",
"private_message": "unknown task: foo-bar"
}
will be wrapped in a standard one
{
"errorMessage": "{\"code\":\"TASK_NOT_FOUND\",\"public_message\":\"Task not found\",\"private_message\":\"unknown task: foo-bar\"}",
"errorType": "lambdaError"
}
and later on mapped in API Gateway, so, the end client will see only the public message
{
"code": "TASK_NOT_FOUND",
"message": "Task not found"
}
I'm trying to use the "whisk.system/messaging" and trying to use the method messageHubProduce.
I created a bind to this package, and tried to use a simple call with postman.
Using the documentation, I created a simple json and did a call, but the method is really unstable. The same call sometimes return as a success, sometimes returns a timeout and sometimes as a "No brokers available".
I now the implementation of this code is on python. Have anyone with the same symptoms I getting?
This is the message I'm sending.
{
"topic": "mytopic",
"value": "MyMessage",
"blocking": false
}
These are the results for the same call
messageHubProduce 446d59eb816b4b34a52374a6a24f3efe
{ "error": "The action exceeded its time limits of 60000 milliseconds." }
messageHubProduce 4213b6a495bc4c5aa7af9e299ddd8fcd
{ "success": true }
After working closely with the Message Hub team, we have deployed an updated messageHubProduce action which should address your stability and performance issues.
Additionally, to provide real-time feedback please feel free to join us on Slack: https://openwhisk.incubator.apache.org/slack.html