+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
