@revenexx/app-sdk@0.7.2

Patch Changes

• f90dc8e: Answer a jsonb list filter that is not a JSON document with our own 400, instead of forwarding it and letting the data plane fail the cast (PE-462).

  mountCrud turned any query key naming a column into an equality without looking at the column type, so a filter on a jsonb column went to PostgREST as col=eq.<junk>. Postgres failed the cast (SQLSTATE 22P02) and the caller got a 400 that named neither the parameter nor what a good value looks like — after a round trip to the data plane:

  GET /v1/forms?definition=x
    -> 400 {"error":"a value in the request has the wrong format","code":"invalid_value"}
  

  It is our query parameter, so it is our 400. The rule is exactly the data plane's: the value must parse as JSON. Same status and same code as before — only the message becomes actionable, and the round trip disappears.

  Nothing that worked stops working. A filter on a jsonb column has always been a whole-document equality, and Postgres compares jsonb semantically, so key order and whitespace stay irrelevant and an exactly-serialised document is still forwarded unchanged. A JSON scalar (?position=5) is valid JSON and still goes through.

  Deliberately not a containment (cs.) filter, and jsonb columns are deliberately not skipped: four apps declare these filters as equality, with JSON examples. Widening them is a product decision, not a bug fix; dropping them would turn the one form that works into a silent no-op.

  A query key naming no column at all is unchanged — it is still dropped rather than refused, because the filter object in every list response already reports exactly which keys were honoured, and 400ing instead would break every client that carries a stray parameter across thirteen live apps.

  Also corrects the runtime/remote adapter comments about X-Revenexx-Market, which described it as a read-side scope filter. Comment only, no behaviour.