Skip to content

fix hanging requests and filters read with the wrong CRS under concurrent requests - #656

Open
cportele wants to merge 2 commits into
masterfrom
api-validation-fixes-part1
Open

cportele wants to merge 2 commits into
masterfrom
api-validation-fixes-part1

Conversation

@cportele

Copy link
Copy Markdown
Contributor

Two major fixes found by testing several ldproxy APIs with schemathesis and under parallel load.

  • Requests hanging when the database rejects the first query of a feature stream
    (FeatureStreamImpl): the collection metadata of a feature stream is published when the stream
    starts, which for SQL is the first row of the meta query. When the database rejected that query
    (e.g. a filter value that PostgreSQL does not accept), the stream ended with the error without
    ever starting, a caller waiting for the metadata blocked forever, and the error was never logged.
    Each such request kept a request thread. FeatureStreamImpl now completes the metadata with the
    stream error (or an IllegalStateException, if there is none) when the stream ends before it
    started. Single features were not affected (their stream starts before the query is executed).
    The read-stall timeout does not apply in this case, the read has already ended.
  • Concurrent CQL2-JSON filters read with the wrong CRS (CqlImpl): the CRS of the coordinates
    was set as injectable value on the shared object mapper before a filter was read. Under
    concurrent requests a filter could be read with the CRS of another request, e.g. a stored query
    with coordinates in EPSG:25832 was read as CRS84; the coordinates were then rejected, an internal
    error, also after the response had been started (truncated JSON with status 200). The CRS is now
    bound to the reading thread. (A per-call ObjectReader does not work: nested deserializers get
    the shared mapper as codec.)

The CRS of the coordinates in a CQL2-JSON filter was set on the shared object
mapper before the filter was read. With concurrent requests, a filter could be
read with the CRS of another request, e.g. a stored query with coordinates in
EPSG:25832 was read as CRS84. The coordinates were then rejected as invalid,
which failed the request with an internal error, also after a response had
already been started.

The CRS is now bound to the thread that reads the filter.
…eature stream

The collection metadata of a feature stream is published when the stream
starts. When the first query fails (e.g. a filter that the database rejects),
the stream ended with the error without ever starting, and a caller waiting
for the metadata blocked forever; the error was never logged.

The metadata is now completed with the stream error when the stream ends
before it started.
@cportele
cportele force-pushed the api-validation-fixes-part1 branch from e3b38b3 to a139b09 Compare October 19, 2026 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant