openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dascalita Dragos <ddrag...@gmail.com>
Subject Re: Transactionid in the ErrorResponse
Date Fri, 20 Apr 2018 15:22:14 GMT
+1 to make the “code” field a string

and +1 should we choose to rename it into what it is: “id” instead of
“code”; “code” may still be used but it’s semantincs would be given by
static codes (I.e HTTP Status Codes )

If we’re interested to bring more structure we can look at some ongoing
specs efforts such as [1]

[1] - http://jsonapi.org/format/#errors


On Thu, Apr 19, 2018 at 12:49 PM Carlos Santana <csantana23@gmail.com>
wrote:

> We just need to find the floating spec and updated with the new schema.
>
> Also `code` is not documented as top level API or documentation, didn't
> find in the swagger doc [1]
>
> + 1 to change and adjust downstreams (i.e. CLI, etc..)
>
> [1]
>
> https://github.com/apache/incubator-openwhisk/blob/master/core/controller/src/main/resources/apiv1swagger.json
>
>
> On Thu, Apr 19, 2018 at 12:04 PM Nick Mitchell <moosevan@gmail.com> wrote:
>
> > it's unlikely, for sure, but e.g. there may be a typescript spec floating
> > around out there
> >
> > On Thu, Apr 19, 2018 at 11:58 AM, Rodric Rabbah <rodric@gmail.com>
> wrote:
> >
> > > 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