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 <fmesc...@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 <rod...@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 <ddrag...@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 <rod...@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 蒋鹏程 <jiang.pengch...@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 > > > > > > > > > > > > > > > > > >
