Skip to content

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

Merged
azahnen merged 2 commits into
masterfrom
api-validation-fixes-part1
Oct 23, 2026
Merged

azahnen merged 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.
@azahnen
azahnen force-pushed the api-validation-fixes-part1 branch from a139b09 to 0ab2837 Compare October 23, 2026 09:56
@azahnen
azahnen merged commit 20ac7d5 into master Oct 23, 2026
3 checks passed
@azahnen
azahnen deleted the api-validation-fixes-part1 branch October 23, 2026 10:14
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.

2 participants