couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@apache.org>
Subject Re: [DISCUSS] Minor replicator error reporting API change
Date Wed, 08 Jan 2020 14:54:31 GMT
Following up on this. It seems fine we use the error message from the
replicator doc instead of the API so it has no effect on fauxton. Nice work
Nick.

On Sun, Dec 22, 2019 at 9:19 AM Nick Vatamaniuc <vatamane@gmail.com> wrote:

> Good point regarding Fauxton, Garren.
>
> Thank you for taking a look at it
>
> I've created the PRs for the implementation and the docs:
>
> https://github.com/apache/couchdb/pull/2379
> https://github.com/apache/couchdb-documentation/pull/465
>
> On Sat, Dec 21, 2019 at 8:03 AM Garren Smith <garren@apache.org> wrote:
> >
> > +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 <
> arturo@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 <
> > > vatamane@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
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message