Error display: errors may be on twice-nested fields

@matthieu @manonbou I came across the following error:

{"batches":{"tasks":{"@id":["task with this urlid already exists."]}},"@context":"https://cdn.happy-dev.fr/owl/hdcontext.jsonld"}

The actual error is serverside, but when it was rendered in the front-end I saw this:

I think this is because the error is nested in batches['tasks']

added BUG label

Yes indeed, what you mean is that we should find a way to display the errors properly even if they are nested?

Yes

assigned to @autodeploy

assigned to @manonbou and unassigned @autodeploy

It occurs to me that we're sending the error in Django format but probably this should be in JSON-LD, using an ontology to describe errors? @balessan

Yes but I have no idea about the error format we could use. Probably something Shex related.

Opened an issue for this here djangoldp-packages/djangoldp#348

mentioned in issue djangoldp-packages/djangoldp#348

changed milestone to %0.16

changed time estimate to 1d

Two questions here:

1. today, we filter all the properties starting by @ in the error we receive. I think the original purpose of this was to remove the @context property of the object before displaying it. But it also removes the @id. Is it something we want?
2. we currently have errors like this:

  {
   "key": ["error"],
   "@context": "thecontext"
  }

Can we also have nested contexts like this?

  {
   "key": 
     {
       "nestedObj": ["error"],
       "@context": "thecontext"
     }
   "@context": "thecontext"
  }

ping @calummackervoy @balessan

after discussion with @balessan , we may want to remove only @context but keep @everything_else.

@calummackervoy, what about the nested context I mentioned above? Is it something we could have?

Is it something we could have?

Do you mean does the server ever return anything like this?

A priori no, are nested contexts part of the JSON-LD spec? I had a look at internationalization, all of the examples define one @context even when multiple language values are being returned

It is part of the spec, for example on container /users/ we have

{
"@context":"https://cdn.happy-dev.fr/owl/hdcontext.jsonld",
"@type":"ldp:Container",
"@id":"https://api.community.startinblox.com/users/",
"ldp:contains":[
    {"@context":{"get_full_name":"rdfs:label"},
     "@type":"foaf:user","@id":"...", 
     "account":{
         "@context":{
           "picture":"foaf:depiction"
         },
         "@id":"..."
...

but I don't think that we return anything like this with our serializer errors

Ok thanks, that was the question. Indeed it happens in the graphs sometimes, but I was wondering for the errors

@manonbou in conclusion, we should remove:

• only @context
• only when at first level of the object.

Your MR may need 1 small change then

mentioned in merge request !565 (merged)

closed