Martin Raifer

> only data extraction endpoints are affected I think this also affects aggregation endpoints, when you – for example – count features with given length/area properties. These requests would be...

FYI: this is already fixed in the oshdb master branch (see https://github.com/GIScience/oshdb/issues/434). We'll wait for a release of the OSHDB to update the documentation here and close this issue.

…or the quality gate definition could be relaxed (adjusted to our actual needs) perhaps. :thinking:

> error and OK at the same time at first glance, this seems like a bug from your description. what kind of request endpoint was this? > Sending this request...

~~rest of query also, please :pray: (see https://github.com/GIScience/ohsome-api/blob/master/.github/ISSUE_TEMPLATE/bug_report.md#general-information)~~ //edit: ah, sorry, there's also a json file included in the zip file. :see_no_evil: sorry for the oversight

one last question: is the snippet above the full result you get, or is there more which you omitted?

OK, this is a data extraction request, which could be a first hint why the status code is 200 "OK": these requests use chunked/streaming data output, where there is no...

That statement is of course true in general. But we are using object serialization quite differently than where it is normally used. We don't use it to actually send data...

> Its just not valid json. yes, that's the expected behaviour for extraction endpoints, as [documented](https://github.com/GIScience/ohsome-api/blob/master/docs/http-response-status.rst#2xx-success): > If an error occurs during a data-extraction request, the result will be a...

I think that the bug doesn't have anything directly to do with the overlapping boundary input data in `bug_both.txt`, because the difference is already visible if only taking `bug_1.txt` into...