Re: Long running invocations and status code (was : [Review]Change return status code for ApplicationError and DeveloperError)

[Rodric Rabbah <ro...@gmail.com>]

There is a timeout parameter on POST activations which is probably not used
much that can serve this purpose (I think it's not documented, I have to
check).
For web actions (request/response) we'd need a header to indicate this
preference.

Assuming the API provided this, which would be the default behavior?

On Thu, Jan 28, 2021 at 5:32 AM Felix Meschberger
<fm...@adobe.com.invalid> wrote:

> Hi all
>
> I am a bit on the edge here: I really like the server (OpenWhisk
> controller ?) to terminate the request with a 202 indicating that the
> processing continues. On the other hand, this really might be coming
> unexpectedly as it is not very mainstream.
>
> How about a compromise ?
>
> RFC 7240 (https://tools.ietf.org/html/rfc7240) defines the Prefer request
> header whether the client can provide a preference for request processing.
> One use case would be to state "please synchronous, but if it takes longer
> than 30s, continue asynchronously".
>
> Granted, this allows clients to indicate their preference, but it does not
> solve the hard problem of "aborting" the invocation: In fact if the
> invocation being executed, then what would "abort" mean anyways ?
>
> Just my 2 cents from the peanut gallery
>
> Regards
> Felix
>
> ________________________________________
> Von: Rodric Rabbah <ro...@gmail.com>
> Gesendet: Dienstag, 26. Januar 2021 06:31
> An: dev@openwhisk.apache.org
> Betreff: Re: [Review]Change return status code for ApplicationError and
> DeveloperError
>
> Thanks for sharing this feedback from developers, Dragos.
>
> Like the PR from Jiang, this is a one line change in terms of the status
> code. Cancelling the request is harder but could be accomplished by
> attaching a deadline on an activation request and allowing the invokers to
> discard them on receipt if they're past their deadline.
>
> I agree for a request/response model, downgrading a synchronous request to
> an asynchronous one isn't ideal.
>
> -r
>
>
> On Mon, Jan 25, 2021 at 9:41 PM Dascalita Dragos <dd...@gmail.com>
> wrote:
>
> > While we're on the status code topic I'd like to share some feedback we
> got
> > from developers using OpenWhisk.
> >
> > They have complained that for blocking activations, when the system can't
> > execute the action, they get a 202 instead. The feedback was that it's
> not
> > correct for a system to override the intention of the developer, and that
> > the correct response should be an error status code. The system should
> also
> > stop the execution to avoid wasting resources. Since OpenWhisk actions
> can
> > be invoked from a browser too (HTML content, or other content type that
> can
> > be displayed by the browser), dealing with a 202 becomes complicated, and
> > it's not in line with its purpose either [1] "cases where another process
> > or server handles the request, or for batch processing".
> >
> > [1] - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202
> >
> > On Mon, Jan 25, 2021 at 7:00 AM Rodric Rabbah <ro...@gmail.com> wrote:
> >
> > > Thanks Jiang for addressing this long standing bug.
> > >
> > > I reviewed the PR. The 400 status code for developer errors also
> matches
> > > the web action response. I think the only real debate is whether
> > > application error should be 207 or 400. If a web action responds with
> an
> > > error and no explicit status code, is it treated as a 20x response. So
> I
> > > find the change in your PR consistent.
> > >
> > > There may be some effects to check in the npm client and the wsk (or
> > other
> > > clis).
> > >
> > > -r
> > >
> > > On Mon, Jan 25, 2021 at 1:19 AM 蒋鹏程 <ji...@navercorp.com>
> > wrote:
> > >
> > > > Dear whiskers:
> > > > ​
> > > >   Currently we are using 502 BadGateway for ApplicationError and
> > > > DeveloperError, which is not very appropriate I think, so I submit a
> PR
> > > to
> > > > change this:
> > > > ​
> > > > 1. Use MultiStatus for ApplicationError
> > > > 2. Use BadRequest for DeveloperError
> > > > ​
> > > > Any comments and suggestions are welcomed
> > > > ​
> > > > refs:
> > > > 1.
> > https://github.com/apache/openwhisk/issues/645#issuecomment-232534948
> > > > 2. https://github.com/apache/openwhisk/pull/5047
> > > > ​
> > > > Best Regards
> > > > Jiang Pengcheng
> > > >
> > > > ​
> > > >
> > >
> >
>