Two query providers disagree about which selectors exist: 'compilationStatus' resolves on Postgres and is blind in QueryEvaluator, with no test comparing them #3511

Activity

1. rbuergi commented on Sep 7, 2026

   

   rbuergi

   on Sep 7, 2026

   ContributorAuthor

   More actions

   🚨 Correcting my own filing: the defect is real, the fix I proposed is wrong — and the right one is a single string

   I said this needed a Content fallback in GetDirectPropertyValue or a selector→content-path mapping,
   and called that "a behaviour change for every query [that] needs its own thought". That is not
   required. The instrument is simply written with the wrong selector.

   QueryEvaluator.GetPropertyValue splits the selector on . and walks it:

   var parts = selector.Split('.');
   foreach (var part in parts) { … current = GetDirectPropertyValue(current, part); }

   Content IS a public property of MeshNode (one of 24 reachable selectors: Category, Content, CreatedBy, CreatedDate, Description, DesiredId, ExcludeFromContext, HasExplicitMainNode, HubConfiguration, Icon, Id, IsDefinitionOnly, IsSatelliteType, LastModified, LastModifiedBy, MainNode, Name, Namespace, NodeType, Order, PreRenderedHtml, State, SyncBehavior, Version). So a dotted
   selector reaches straight into the content — and the second hop works on both content shapes:
   typed, via reflection with IgnoreCase; untyped JsonElement, via GetJsonPropertyValue, which has
   its own case-insensitive fallback. QueryParser accepts . in a selector token (QueryParser.cs:868).

   And this is the established idiom, not a discovery — it is what production code already does:

   src/MeshWeaver.Graph/UserActivityLayoutAreas.cs:550   nodeType:AccessAssignment content.accessObject:{ownerId}
   src/MeshWeaver.Graph/UserActivityLayoutAreas.cs:668   nodeType:Thread -content.status:Done sort:LastModified-desc
   src/MeshWeaver.Graph/SpaceInviteService.cs:66         nodeType:User content.email:{normalizedEmail}
   src/MeshWeaver.Graph/GroupInviteExtensions.cs:93      nodeType:User content.email:{normalizedEmail}
   Doc/Architecture/NoStaticState.md:181                 nodeType:ApiToken content.tokenHash:{hash} limit:1
   

   So the fix is:

   - search 'nodeType:NodeType compilationStatus:Error'
   + search 'nodeType:NodeType content.compilationStatus:Error'

   One string in AGENTS.md. 🚨 It is a shared rule block, so it changes in every repo of the fleet
   together — that is the only reason this is not a two-minute change.

   This makes the issue more urgent, not less. The defect is unchanged — the documented instrument
   returns nothing, on every backend, and reads as a clean mesh — but the remedy is cheap and safe
   rather than a query-engine change nobody wanted to make during a release.

   The falsification now has two arms, and both should be run together

   On a mesh known to hold a NodeType in Error:

   	expected if this issue is right
   search 'nodeType:NodeType compilationStatus:Error'	returns nothing
   search 'nodeType:NodeType content.compilationStatus:Error'	returns the node

   Both arms matter: the first alone could be explained by there being no Error node, which is exactly
   the ambiguity this issue is about. 🚨 Still a code read, not an execution — I have not run either.

   One consequence worth stating

   Every agent that has followed AGENTS.md's sweep instruction has run a query that cannot match, and
   had no way to tell that from a clean mesh — the denominator recommendation stands for that reason
   alone: the sweep should report how many nodeType:NodeType nodes it examined, so 0 of 0 and
   0 of 412 stop spelling the same thing.
2. rbuergi commented on Sep 7, 2026

   

   rbuergi

   on Sep 7, 2026

   ContributorAuthor

   More actions

   Measured on the live Postgres-backed mesh (memex MCP), 2026-09-07 00:3xZ — the sweep DOES discriminate there

   query	count
   nodeType:NodeType compilationStatus:Error	5 — LinkedIn/Skill, Store/Catalog, Store/Maintenance, Store/Order, Store/Plugin
   nodeType:NodeType content.compilationStatus:Error	5 — the same five
   nodeType:NodeType compilationStatus:Ok	195, and none of the five is among them
   nodeType:NodeType	>200 (truncated at the limit)

   So on the production path the bare selector selects the Error set exactly: the Postgres provider must be mapping a field that is not a MeshNode column into the content JSONB — the parser passes compilationStatus through unprefixed (checked at 155b4fa17: the term becomes the selector as written), and the in-process QueryEvaluator.GetDirectPropertyValue has no Content fallback, as the body says. The claim that holds is narrower than filed: the in-memory evaluator is blind to Content fields; the Postgres SQL path is not. That leaves the sweep valid on the AKS portals (PG) and invalid on anything the in-memory evaluator serves — a Monolith on the file adapter, static nodes, tests — which is worth fixing with a Content fallback in the evaluator, and worth a test that runs the same query through both providers and demands the same answer.

   Note what the working sweep found tonight: four Store/* NodeTypes in Error since 22:39:32Z on this instance — a separate issue follows.
3. rbuergi commented on Sep 7, 2026

   

   rbuergi

   on Sep 7, 2026

   ContributorAuthor

   More actions

   🚨 CORRECTION — "reaches nothing, every backend" is FALSE. The bare form works on Postgres.

   Measured on the live Postgres mesh by another session, and it settles it:

   query	result
   nodeType:NodeType compilationStatus:Error	5 (LinkedIn/Skill, Store/Catalog, Store/Maintenance, Store/Order, Store/Plugin)
   nodeType:NodeType content.compilationStatus:Error	the same 5
   nodeType:NodeType compilationStatus:Ok	195, none of the five among them
   nodeType:NodeType	>200

   The bare predicate discriminates on the production path — the Postgres provider maps a non-column
   field into the content JSONB. So the sweep AGENTS.md prescribes is not blind on an AKS portal,
   which is where it is actually run before a deploy. My headline claim was wrong and would have misled
   the next reader in the most consequential place.

   Where my code read was right, and it is a narrower thing: the in-memory QueryEvaluator has
   no Content fallback, so GetDirectPropertyValue returns null for compilationStatus against a
   MeshNode. That makes the bare form blind on the Monolith/file adapter, static nodes and tests —
   a real gap, and the reason a test written against those hosts cannot catch a regression in the other.

   What I got wrong, and why, since the mechanism is the reusable part: I saw
   StorageAdapterMeshQueryProvider hold private readonly QueryEvaluator _evaluator = new(); and
   concluded every storage-backed path — Postgres included — matched through it. It does not; there is a
   Postgres-specific query path that pushes the predicate into SQL. 🚨 The falsifying artefact was in my
   own terminal minutes earlier: a doc line naming PostgreSqlPartitionedMeshQuery.EnumerateFanOutAsync.
   I read it and did not apply it. "A field held is not a field used on every path" — the same shape as
   reading a gate's presence as its coverage.

   What still stands

   • The AGENTS.md string should still become content.compilationStatus:Error — it is the
     established production idiom, it works on every path, and it removes the split entirely.
   • QueryEvaluator should get the Content fallback, so the two providers answer the same
     question the same way.
   • 🚨 And the test that proves it must run ONE query through BOTH providers. That is the actual
     defect this issue should carry: two implementations of one query language, disagreeing about which
     selectors exist, with no test that compares them. Every consequence here — including my wrong
     conclusion — follows from that.
   • The denominator recommendation is unchanged and is now better motivated: a sweep that returns
     0 should say 0 of 412, so a blind path and a clean mesh stop spelling the same thing.

   The title is now wrong too and should be re-scoped to the evaluator/provider divergence rather than
   the sweep.
4. rbuergi

   changed the title [-]The prescribed pre-prod NodeType sweep matches nothing: 'compilationStatus' is not a property of MeshNode and QueryEvaluator has no Content fallback[/-] [+]Two query providers disagree about which selectors exist: 'compilationStatus' resolves on Postgres and is blind in QueryEvaluator, with no test comparing them[/+] on Sep 7, 2026
5. rbuergi

   added a commit that references this issue on Sep 7, 2026

   Make the sort comparator total — the fallback made its partiality rea…

   ...

   e71ffa3
6. rbuergi

   closed this as completedon Sep 7, 2026