In SlashDB, whenever a pass-through query can be executed, the HTTP code returned is always in the 200-class (OK, Created, etc.). Unfortunately, this doesn't account for cases when an error should be returned, such as: item doesn't exist in a table, etc.
Is it possible to force an error code from a pass-through query?
UPDATE:
I understand it is a an interminable debate whether a valid query should return an error code if it returns an empty set. There are valid arguments on both sides. I happen to think that if we think, say, a serial number is a resource and it doesn't exist, the call should return an error. Some details can then be placed in the response body as to how to further process the problem.
This question is not an attempt to seek answer to the aforementioned debate, but merely trying to discover whether there is a way in SlashDB to affect the HTTP error codes when using the SQL Pass-thru feature.
It's debatable if a query returning no rows is an error condition that would warrant a 404 Not Found. SlashDB behaved that way in earlier versions, but many developers complained.
Now, as long as the query is valid and executes without issues you will get a result and a 200 OK. It can be an empty list i.e. [], if there are no rows matching your query conditions.
Other error codes can be returned too. For example you will get a 403 if you don't have permissions.
Generally HTTP codes in the 4xx series indicate there's something wrong with a client's request. Codes in the 5xx series indicate some unexpected condition with the server i.e. database is down or time out from heavy traffic.
If this explanation does not address your particular query, please update your question with the query example and pertinent information about your database schema.
There doesn't seem to be a way to handle this in SlashDB. My solution to this is to declare an error on the MySQL side and a message_text to describe the problem. Because of this error, SlashDB returns an ambiguous 500 code.
It's a brute force solution, but it eliminates the ambiguity for now.
Related
To create custom error handling I would like to switch at the errorcode property of a MongoDbException.
Is there any official list of error codes?
I know 112 is a WriteConflict, 16608 means division by 0 and 16610 is a modulo by zero.
error_codes.yml is incomplete and lacks of 16608 and 16610.
I found a list here (the same as yours)link.
In my case, We launched a lot of test scenarios and then i searched in logs all the possible codes. The ones that i found are :
112 write conflict (when a transaction is failed)
11000 Duplicate Key (when a unique constraint index is violated)
211 or 11600 When mongo is down or i have a bad config
So If we don't have a better solution. All we can do is handling the most redundant cases. The other cases are handled as 500 server error.
MongoDB server source code is publicly available, if you want to get information about a particular error, or get a list of all errors, going through the source is going to be your best bet.
Per Daemon Painter's comment, there is an open docs ticket to provide a list of error codes.
One challenge with such a list is the server does not guarantee when it will produce a particular error code. Therefore a comprehensive list of error codes either would be not very useful (if it only tells you what error codes exist but not when you would get them) or it would be labor-intensive to maintain.
The drivers generally look for certain error codes in certain situations only (see for example here). They don't have a complete list of error codes.
I'm currently facing a dilemma in choosing the most appropriate response for a REST API that GET multiple entities, when one of the entities has a data corruption error. Say I have a REST API like the following:
GET /employees?department=&manager=
that returns a list of employees, perhaps with some filtering applied.
When getting the data from upstream (a DB, or another web service, etc.), I discover that the data for one of the employees that match the condition is corrupted. For example, the data cannot be parsed or does not meet some precondition that is necessary for that data entity.
What would be the most appropriate (from an API point of view) RESTful response to this? Should I continue processing all the other employees and simply ignore the error and omit it in the response, or error out with 500 Internal Server Error, or include the error in the response in a separate field while returning the other "good" employees?
I know this is somewhat opinion-based, but some advice would be greatly appreciated.
If you want to return an error, this (to me) is a server-error and I think that 500 is indeed the most appropriate error.
Whether you want to return an error, or an incomplete list with warnings depends on what your application requires it to do.
Say I am building an API that serves the content of old magazines. The client can request the content of the latest edition prior to a given date, something like:
GET /magazines/<some_magazine_id>?date=2015-03-15
The response includes general data about the magazine, such as its name, country of distribution, the date of creation..., and if my database has content available for an edition prior to the date given, it returns it as well.
What HTTP status code should I use if the client requests data for a date before anything I have available? I might have data in the future, when I expand the content of my database. So this is sort of a temporary failure, but it's unclear how long it may take before it is fixed.
Based on other questions, I feel like:
404 is not right: in some cases, I have no data at all about a magazine, in which case I'd return a 404. But this is different. I would like the user to get the partial data, but with an indication that it's only partial.
4xx are client-side errors. I feel like the client didn't do anything wrong.
206 Partial Content seems indicated when returning a range of the content, but not all of it.
30x I thought about using a 302 or similar, and point to the closest edition available, but again, I am not sure that this is right, because I am now pointing to something semantically different from the question asked.
5xx would be errors, and I think should not contain any data.
My best guess would be something like a 2xx No Details Available (Yet) indicating that the request was "somewhat successful", but I can't find anything that seems correct in the list.
I would go with a 200 OK. You did find the magazine and you are returning data about it. While your data is not as complete as it might have been, it is a complete response that can be understood. Presumably you are returning an empty array or a nil reference where the edition(s) would have been?
The problem with many of the more specific responses are that they are really intended for something more low-level. You are not returning partial content, you are returning the full content. It is just that the higher-level application data is not as complete as you might have wished (no old edition found). On the REST/HTTP level the response is just fine.
I'm writing a RESTful API with some endpoints to which clients can PUT or POST chunked files (using flow.js), including a payload digest among the metadata. The server also calculates digest and will throw an error if the digests don't match, in which case the client should attempt to retry the same request with no change (at least until some retry limit is reached).
None of the standard codes seem to fit well by definition. What is the best code to use? Is there any that fits somewhat by convention?
Note: for the purposes of integration with this library, the response must not be 404, 415, 500, or 501 as they will cancel the larger operation rather than retry this portion.
I also cannot use 409 because that is being used to identify attempts to upload multiple copies of the same file, which I believe is a better use of 409 anyway.
I think more appropriate status code when same data from user going wrong, like corrupted data is:
400 Bad Request
For me corrupted data, means like syntax error caused by the transmission of data, semantically correct but syntactically erroneous.
422 Unprocessable Entity maybe apply too.
https://www.rfc-editor.org/rfc/rfc4918#section-11.2
I cannot accept Matthew's answer because it's still suggesting one of the values I'm excluded from using - and I also believe 5xx errors aren't very appropriate where the error is in the client or the transport layer.
While still looking for better options, I'll for now propose (and use) a non-standard 4xx error, especifically
419 Checksum failed
That particular value is being chosen for its proximity to codes handling errors of a similar nature and similarity to 409 which is perhaps the closest relation.
An anser will be chosen after a couple days, to provide opportunity for community concensus on a best practice approach.
I am not aware of a standard or specific error number for a case like this but normally I would use 415 or 500. Since you are restricted from using those options I would go with a 501. Technically a 501 is a "not implemented" but it is used in cases where there server does not recognize the request OR the server lacks the ability to fulfill the request. You could argue that a checksum error makes it impossible for the server to fulfill the request.
If you want to see a list of all the options check out this wiki page and you might find something you like better
When user is registering on website, e-mail needs to be provided which is unique. I've made unique index on schema's email attribute, so if I try to save the document in database, error with code 11000 will be returned. My question is, regarding to business layer and data layer, should I just pass the document to database and catch/check error codes which it returns or should I check if the user with that e-mail exists before? I've being told that data integrity should be checked before passing it to the database by the business layer, but I don't see the reason why should I do that since I believe that mongo would be much faster raising the exception itself since it has that index provided. The only disadvantage I see in error code checking is that error codes might change (but I could abstract them) and the syntax might be changed.
There is the practical matter of speed and the fragility of "check-then-set" systems. If you try and check if an email exists before you write the document keyed on email, there is a chance that between the time you check and the time you right the conditions of the unique index are met and your write fails anyhow. This is a classic race condition. Further, it takes 2 queries to do check-then-set but only 1 query to do the insert and handle the failure. In my application I am having success with just letting the failure occur and reacting to the result.
As #JamesWahlin says, it is the difference between dong this all in one or causing mixed results (along with the index check) from potential race conditions by adding the extra client read.
Definitely rely on the response of only insert from MongoDB here.