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 <gar...@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 <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 > >
