You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2021/01/29 16:35:44 UTC

[GitHub] [couchdb] nickva commented on a change in pull request #3355: Handle all erlfdb error codes

nickva commented on a change in pull request #3355:
URL: https://github.com/apache/couchdb/pull/3355#discussion_r566946001



##########
File path: src/chttpd/src/chttpd.erl
##########
@@ -1051,6 +1045,160 @@ error_info({Error, Reason, _Stack}) ->
 error_info(Error) ->
     maybe_handle_error(Error).
 
+
+erlfdb_error_info({erlfdb_error, ErrorCode}) ->
+    StatusCode = fdb_error_to_http_status_code(ErrorCode),
+    ErrorName = fdb_error_name(ErrorCode),
+    ErrorDesc =  erlfdb:get_error_string(ErrorCode),
+    {StatusCode, ErrorName, ErrorDesc}.
+
+
+fdb_error_to_http_status_code(2101) ->
+    413;
+fdb_error_to_http_status_code(2102) ->
+    413;
+fdb_error_to_http_status_code(2103) ->
+    413;

Review comment:
       In many cases I've seen so far 2103 and 2102 where generated due to bugs or misconfiguration. Emitting 413 http error for those cases might affect replication, as the replicator will assume a 413 error is because the document has exceeded a configured size and skip over it and continue on.
   
   I wonder if 2102 (`key_too_large`) may be a case of an 414 (uri too long) HTTP code too.  It depends where it would come from in the code. Maybe if there is a too large a `max_document_id_length`? I think it may even be set to `infinity` currently which is silly. We should have a ceiling there as well just as discussed in https://github.com/apache/couchdb/issues/3354




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org