Query::isSatisfiedBy() considers an unfiltered answer sufficient for a
filtered query, which is true for a vanilla get: onGetValuesDone() applies
the operation filter to the values before calling back.
A projected query is different. It receives the fields another query selected
and can no longer evaluate its own filters on them, all the more so as those
filters may target fields that were not selected at all. Two concurrent
queries such as "SELECT id" and "SELECT id WHERE value_type=1" therefore made
the filtered callback report identifiers whose type does not match, and
searchNodeGetDone() additionally cancelled its own request so it never got a
correctly filtered answer.
Add Query::isProjectionSatisfiedBy(), which additionally requires both queries
to apply the same filters, and use it for operations with a query callback.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
containedIn() only checked that the other index declared the same field
keys, never that they held the same values, contradicting its documented
contract of containment "with the same value".
Dht::query() uses containedIn() to deduplicate projected results. Because
every result of a given query shares the same projection schema, any two
results compared equal: the first one suppressed all the later ones, and the
"lesser" branch even erased the already reported result. A query selecting a
field therefore reported a single value regardless of how many matched.
Compare the FieldValue as well, and add a regression covering distinct
values, equal indexes and a narrower projection contained in a wider one.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Cover Value::toJson() / Value(const Json::Value&) preservation of the
pushType field, and its absence from the JSON when empty. This is the
serialization path used by DhtProxyClient::put(), so mobile clients
behind a DHT proxy depend on it to propagate the push notification
type.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>