+1 nice improvement. We will have to check and possibly update Fauxton
based on this change.
Once this change is ready to go I can check Fauxton and make sure we
support it or make any required changes.
On Fri, Dec 20, 2019 at 8:47 PM Arturo GARCIA-VARGAS <art...@ficuslabs.com>
wrote:
> +1 - It makes sense for any error object to have an error key
>
> On 20 December 2019 18:33:04 GMT+00:00, Nick Vatamaniuc <
> vatam...@apache.org> wrote:
> >Hi everyone,
> >
> >Before 3.0 goes out, I wanted to propose a minor replicator
> >_scheduler/* API change.
> >
> >Currently when a replication job is crashing it reports the error as a
> >string in the "info" field. So that that "info" field can be null, a
> >string, or an object with various replication stats.
> >
> >The proposal is to turn the string into an object as well with an
> >"error' field. So instead of
> >
> >{
> > ...
> > "info": "some error message"
> >}
> >
> >It will look like
> >
> >{
> > ...
> > "info": {"error": "some error message"}
> >}
> >
> >A few reasons for this change that it's a bit more consistent, and it
> >should help with the some clients in static type language which have
> >harder time handling an object being either a string, or an object, as
> >opposed to a nullable fields and be different objects.
> >
> >What does everything think?
> >
> >Cheers,
> >-Nick
>
