Error returned when unique constraint violated

[Thomas Weiss]

Hi there,

Following the recent issues I had with 2.8, I'm currently evaluating the migration to 3.0 so I'm in the process of porting my Foxx app.

I've just noticed that when a db insert violates a unique constraint on an index, the route now returns with 500 / Internal Server Error, whereas it was just failing by returning the error code 1210 in 2.8... Is that change in interface intended?

Thanks

Thomas

[Kaveh Vahedipour]

Hi Thomas,

this is what I am getting with 3.0 when I violate the uniqueness constraint. 

{"error":true,"errorMessage":"cannot create document, unique constraint violated","code":409,"errorNum":1210}

Could you provide us with a little more detail, plz.

Kind regards,

Kaveh

[Thomas Weiss]

Hi Kaveh,

We must be running different versions because I get a status code 500 with the following body: {"error":true,"errorNum":500,"errorMessage":"Internal Server Error","code":500,"exception":"ArangoError 1210: unique constraint violated","stacktrace":[...]}

That's testing with 3.0.0 on Windows btw, not Ubuntu.

Thanks,

Thomas

[Jan]

I think you're both on the same version (3).
Inserting a document with a uniqueness violation via the HTTP API returns:

  HTTP/1.1 409 Conflict
  Server: ArangoDB
  Connection: Keep-Alive
  Content-Type: application/json; charset=utf-8
  Content-Length: 109

  {"error":true,"errorMessage":"cannot create document, unique constraint violated","code":409,"errorNum":1210}

whereas when the uniqueness violation is triggered from inside a Foxx service, the response is:

  HTTP/1.1 500 Internal Server Error 
  Content-Type: application/json
  Server: ArangoDB
  Connection: Keep-Alive
  Content-Length: 1135

  {"error":true,"errorNum":500,"errorMessage":"Internal Server Error","code":500,"exception":"ArangoError 1210: unique constraint violated","stacktrace":["ArangoError: unique constraint violated","..."]}

So there is indeed a difference in response status codes. I am not sure if this is intentional, probably it is not. Need to find out.

[Thomas Weiss]

Exactly, I got the 500 from Foxx. Behavior was different in 2.8.

[Alan Plum]

Hi Thomas,

when running services in legacy compatibility mode (i.e. running 2.8 services in 3.0) you should still see the old behaviour. Otherwise the change is intentional.

The reason the automatic status codes of internal AranogDB errors are no longer propagated to Foxx by default is that they should be handled explicitly. If you accidentally forget to handle an error and the error propagates to the Foxx error handler that should be detected as a programming mistake (i.e. 500) rather than exposing information about the underlying error to the API client.

For example the Getting Started guide imports the ArangoDB error codes to demonstrate how you can check specific errors: https://docs.arangodb.com/3.0/Manual/Foxx/GettingStarted.html#accessing-collections

The benefit is not as clearly obvious when you just provide a simple CRUD API but this helps maintaining the abstraction between your HTTP API and the underlying database calls.

If you just want the exact same behaviour of 2.8 you can still emulate it using middleware: https://github.com/arangodb/arangodb/blob/3.0/js/apps/system/_api/gharial/APP/gharial.js#L50

Cheers,

Alan