Sync Jobs: Errors not correctly passed through?

[m-mohr]

When sending a pretty "dumb" request (i.e. just copied a collection node in the Web Editor Model Builder and then run it synchronously), the aggregator returns with a very strange response:

It's missing CORS headers, returns text/html(?) and doesn't give any details about the error. Thus a user would be pretty confused about what is going on.

On the other hand, on VITO directly this requests times out at some point. I'm not sure whether this is just trying to load all data?

Process for reference (it doesn't make sense, but I've seen people do that "on purpose" [probably with the intention to get a preview?] and so it should give a reasonable error after a reasonable time:

{
  "process_graph": {
    "1": {
      "process_id": "load_collection",
      "arguments": {
        "id": "AGERA5",
        "spatial_extent": {
          "west": -180,
          "east": 179.9499939,
          "south": -90,
          "north": 90
        },
        "temporal_extent": null,
        "bands": null
      },
      "result": true
    }
  },
  "parameters": []
}

[soxofaan]

I can not reproduce this exactly at the moment (I get Connection reset by peer instead of a 502 with HTML payload) but I think it caused by the whole setup of the aggregator:

 client <-> aggregator proxy system <-> gunicorn app server <->  aggregator web app <->  backend proxy system <-> backend app server <-> backend web app

In the context of extremely long requests, each of these components has some kind of timeout mechanism, but not all are openEO-API-aware (at the moment), and know how to properly return an error message (defaults are typically generic HTML-style error pages) In this case I guess the HTML you got came from the aggregator proxy. I'll have to check if it's possible to set it up so that it returns a generic error in JSON format. I'm not sure how far we can go to make the error more informative (is it a timeout, is it a connection issue, is it a OS issue, ...?)

[soxofaan]

(internal ticket ref: EP-4048)

[m-mohr]

Could be that the Browser puts some defaults if nothing useful is returned and as a Browser is primarily for HTML, I guess this could also just be an invalid/empty response. Anyway, the main point is that the aggregator should return JSON errors compliant with the API. :-)

[soxofaan]

the aggregator webapp will return JSON formatted errors, but if the proxy/loadbalancing system kills the request before that, you get these generic, non-helpful error payloads