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 > > > > > > > > > > > >
