Thank you, Garren!
On Wed, Jan 8, 2020 at 9:54 AM Garren Smith <gar...@apache.org> wrote: > > 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 <vatam...@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 <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 > > > > > >
