openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Mitchell <moose...@gmail.com>
Subject Re: Transactionid in the ErrorResponse
Date Thu, 19 Apr 2018 15:51:38 GMT
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