openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <rod...@gmail.com>
Subject Re: Transactionid in the ErrorResponse
Date Thu, 19 Apr 2018 15:58:43 GMT
It is changing the schema for the error response, but I'm having a hard
time thinking of a case where a client depends on the value of the "code"
(so that a change from int to string becomes a problem) - do you have an
example?

Renaming "code" would be more worrisome to me, but apart from the CLI, I
suspect - with no evidence to back this up other than my intuition - that
it's not used that heavily.

-r

On Thu, Apr 19, 2018 at 11:51 AM, Nick Mitchell <moosevan@gmail.com> wrote:

> this seems like a breaking API change. e.g. in nodejs `===` checks would
> break.
>
> On Thu, Apr 19, 2018 at 11:37 AM, Rodric Rabbah <rodric@gmail.com> wrote:
>
> > Should we also rename “code”?
> >
> > I don’t see the value in using code: 0 and changing the schema should be
> > fine and better in the long run.
> >
> > -r
> >
> > > On Apr 19, 2018, at 11:31 AM, Christian Bickel <apache@cbickel.de>
> > wrote:
> > >
> > > Hi,
> > >
> > > I'm currently working on a PR which basically moves the transactionId
> > generation from the controller to the entrypoint of the system. This is
> the
> > nginx or a frontdoor above.
> > > One change in this PR is to change the format of the tid from a number
> > to a String.
> > > This works pretty well except one change, that could be seen by users.
> > > If there is an error in our system, we return an error response with a
> > short description and the tid. Until now the tid was a number, so the
> value
> > in the JSON has no quotes. With this change, the response message would
> > change, because the tid is a String.
> > > This means the response would change from
> > > ```
> > > {
> > > "error": "This is the description",
> > > "code": 123
> > > }
> > > ```
> > > to
> > > ```
> > > {
> > > "error": "This is the description",
> > > "code": "123"
> > > }
> > > ```.
> > >
> > > Do you agree, that this change would be OK?
> > > An alternative would be to always return a 0 and add an additional
> field
> > with our new tid-format.
> > >
> > > If there are no concerns, I'll go ahead and change the field from the
> > number to a String.
> > >
> > > Greetings
> > > Christian Bickel
> >
>

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