Raise an error immediately if request is deemed "too heavy"

[bossie]

At the moment, the spec recognizes the fact that some process graphs might be considered too heavy for synchronous processing: "Only lightweight computations, for example small previews, should be executed using this approach as timeouts are to be expected for long-polling HTTP requests."

In order to prevent to back end implementation from executing a process graph of which it knows that it will eventually time out, it might be beneficial to raise an error immediately. An example might be a process graph that does not include spatial bounds and will trigger whole-world processing in the back end implementation.

If and when this error will be raised will be at the discretion of the particular back end implementation.

I'm thinking of a 403 (Forbidden) error with an appropriate code and message.

[m-mohr]

It depends on the back-end if a request is too heavy or not and back-ends may not know in advance if a process graph is too heavy. For back-ends it is a good idea to throw an error as fast as possible if it seems to heavy, but it may not even be a timeout from the back-end, but a client that cuts the connection. So I'm having a hard time to really specify this in the API spec. The sentence you quoted was more an informal note and of course back-ends are free to return an error whenever feasible.

Should we change it to the following?

Only lightweight computations, for example small previews, should be executed using this approach as timeouts are to be expected for long-polling HTTP requests. Back-ends may send an error immediately if the computation is expected to time out.

[m-mohr]

Oh, I just saw that the sentence is not actually part of the API spec, but part of the glossary. Therefore I did not make the change as proposed above, but changed the actual description in the OpenAPI file. Here's the commit: 620e8c7c979d34be0e0c9663e4b45e79b2561320 If there's still room for improvement feel free to comment and I'll re-open this issue.