This is an automated email from the ASF dual-hosted git repository.

jsinovassin pushed a commit to branch UNOMI-984-untyped-search-condition
in repository https://gitbox.apache.org/repos/asf/unomi.git

commit 53c436f1efa9736a11a8a7d5aa86c504ab32a30a
Author: jsinovassin <[email protected]>
AuthorDate: Wed Sep 16 17:58:32 2026 +0200

    UNOMI-984: Record how 3.1 answers a search condition with no resolvable type
    
    A search body carries a condition, and 3.1 resolves that condition by its 
type before it runs the
    query. A condition with no resolvable type answers an empty list, and the 
server logs the reason.
    Apache Unomi 3.0 answered the same body by running the query with no 
condition at all, which
    returned every item.
    
    The two answers are opposite, and neither the request nor the response says 
which one the caller
    got. Only the server log does. The migration guide did not record the 
change.
    
    Running a query whose condition could not be resolved widens the search in 
silence, so the 3.1
    answer is the safer of the two. This commit therefore records the change 
rather than reverting it.
    
    The new section sits next to the client-facing hardening section, which 
already records the other
    behaviour changes of 3.1. It states what changed, which endpoints it 
reaches, and how a client
    states matchAllCondition to search over everything.
---
 .../asciidoc/migrations/migrate-3.0-to-3.1.adoc    | 42 ++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/manual/src/main/asciidoc/migrations/migrate-3.0-to-3.1.adoc 
b/manual/src/main/asciidoc/migrations/migrate-3.0-to-3.1.adoc
index 59350e8ec..663937659 100644
--- a/manual/src/main/asciidoc/migrations/migrate-3.0-to-3.1.adoc
+++ b/manual/src/main/asciidoc/migrations/migrate-3.0-to-3.1.adoc
@@ -224,6 +224,48 @@ Anonymous browsing, personas and profile overrides are 
otherwise unchanged, and
 * A backend that named a profile through body `profileId` while authenticating 
with a *public* key must switch to a tenant private key, or to system 
administrator credentials. Until it does, the server logs a `WARN` naming the 
ignored `profileId` on every such request.
 * A client that supplied a session id it did not own now finds `sessionId` 
absent from the response. Treat that as "start a new session" and generate a 
fresh id rather than replaying the old one.
 
+[#_search_conditions_state_a_type]
+==== A search condition states its type (3.1)
+
+A search body carries a `condition`, and 3.1 resolves that condition by its 
`type` before it runs the query. A condition with no resolvable type answers an 
empty list, and the server logs the reason:
+
+[source]
+----
+WARN ParserHelper       | Condition has no type ID for profile search
+WARN ProfileServiceImpl | Cannot execute query: condition type 'null' could 
not be resolved
+----
+
+3.0 answered the same body by running the query with no condition at all, 
which returned every item. The two answers are opposite, and neither the 
request nor the response says which one you got.
+
+.What changed
+[cols="1,2,2", options="header"]
+|===
+| Body | 3.0 | 3.1
+
+| `"condition": {}`
+| The condition was dropped, and the search returned every item.
+| The search returns an empty list.
+
+| `"condition"` naming a type the server does not know
+| The condition was dropped, and the search returned every item.
+| The search returns an empty list.
+|===
+
+This affects every endpoint that takes a `Query`, among them 
`/cxs/profiles/search`, `/cxs/profiles/search/sessions` and 
`/cxs/profiles/personas/search`.
+
+===== Migrating a client
+
+* A client that searched over everything by sending an empty condition states 
`matchAllCondition` instead:
+
+[source,json]
+----
+{ "text": "", "offset": 0, "limit": 1000,
+  "condition": { "type": "matchAllCondition", "parameterValues": {} } }
+----
+
+* A client that omits the `condition` field entirely still searches over 
everything, and it needs no change.
+* A client whose condition names a type that the server does not know now 
reads an empty list where it used to read every item. Check the server log for 
the condition type it names, and deploy the plugin that defines it.
+
 === Migrating your existing data
 
 ==== Multi-Tenancy Impact

Reply via email to