ServiceError.Field *string

[lawrencejones]

Some errors generated by Goa are specific to fields- this commit ensures
we populate Field of ServiceError when this is the case.

An example would be when a field has a validation like MinLength(1) or
similar, where the cause of the error is a specific part of the payload.

It's often useful to retrieve this field, so that people can use this
field to attach errors to the right form input, this being just one
important use case.

[lawrencejones]

This was related to my discussion: #2901

This PR allows my custom error formatter to build richer errors, transforming the standard goa.ServiceError into this:

{
  "type": "validation_error",
  "status": 422,
  "request_id": "unknown",
  "errors": [
    {
      "code": "invalid_field",
      "message": "length of body.name must be greater or equal than 1 but got value \"\" (len=0)",
      "source": {
        "field": "name",
        "pointer": "/name"
      }
    },
    {
      "code": "invalid_field",
      "message": "length of body.description must be greater or equal than 1 but got value \"\" (len=0)",
      "source": {
        "field": "description",
        "pointer": "/description"
      }
    }
  ]
}

[raphael]

This looks great and could be really useful when writing custom error formatters. One thing to think about: could this introduce a backwards incompatible change? I think it should be OK given that this is adding fields and not changing or removing existing ones.

[lawrencejones]

Hey @raphael, sorry for the delay in getting back to you!

One thing to think about: could this introduce a backwards incompatible change?

I don't think it can, as the original error struct should be unchanged. I've been quite careful to leave the original merging behaviour untouched, and all the new information is stored in the History only.

So I think we should be fine to merge this as a non-breaking change?

[raphael]

Makes sense. I see that the build is breaking because of a linting error:

pkg/error.go:210:24: methods on the same type should have the same receiver name (seen 1x "e", 2x "s") (ST1016)

Would you mind taking a look? You can run make locally to make sure the build works, thank you!

[lawrencejones]

Yep, I'll take a look tomorrow. Thanks!

[lawrencejones]

Tomorrow was extremely optimistic- I should have fixed that linting error now, though :)

[raphael]

Looks great, thank you!