Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Root-wide AccessAssignment read fanned out across every partition schema on the memex portal

Aperta
  • Qualcosa non va?
#7,090 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp, postgresql
Ambito
databases

Direzione di ricerca

Start with PostgreSqlPartitionedMeshQuery and the UnanchoredQueryCensusTest corpus in test/Memex.Portal.Shared.Test; compare this query shape with the anchored and declared shapes in SecurityQueries and the Unanchored Security Reads page. First identify the caller and whether the query recurs, using the pod request or audit log at the recorded time and the census test. Done means the responsible read is identified and its handling respects the security constraints for mesh-wide AccessAssignment reads.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug sev:M

Observed

The Postgres query planner (PostgreSqlPartitionedMeshQuery, MeshWeaver.Plugins) served the query

path:@ scope:descendants nodeType:AccessAssignment select:path,id,namespace,name,nodeType,content limit:all

on the memex portal pod as an unanchored fan-out: the base path is bare @ (root), which names no partition, and the shape is not listed in unanchored-queries.allow. The host runs UnanchoredQueryPolicy.ServeAndReport, so instead of refusing (as a CI build would), the planner executed the read as a UNION across every partition schema and logged [FanOut] UNANCHORED with UnanchoredQueryException. This is the full-content bulk read of every AccessAssignment node in the mesh — the query that grants and denies permissions.

Where and when

A single occurrence, on the single portal pod memex-portal-deployment-c67994b85-4297g, at one instant (2026-10-23T14:12:39Z). No burst, no recurrence in the window, one pod of one instance — an isolated invocation, not a per-render storm. Nothing adjacent in the incident window ties it to a deploy, restart or sync.

Impact

The read was served, so no user-visible failure is evidenced at the log site. The cost paid is the one the fan-out census measured (#2640/#3202): an every-partition-schema UNION locks the relations of every schema for its duration, queuing other callers behind it. One execution on one pod is a nuisance-class event, not an outage — but the same shape at render-path frequency is the ~2 s floor the elimination work exists to remove.

Not established

  • The caller. The incident carries only the query provider's frame; no application frame, user identity, request path or agent thread is on it. I could not determine whether the query came from a portal surface, an MCP/agent read, or a core code path.
  • Whether it recurs. One occurrence is consistent with a one-off ad-hoc read and with the first invocation of a newly shipped surface alike.
  • What the result was used for — the read completed under ServeAndReport, but nothing in the incident says who consumed the rows.
  • Whether other log sites (e.g. PostgreSqlCrossSchemaQueryProvider) recorded the same instant — outside this incident's capture.

Candidate causes and the reading that separates them

  1. An ad-hoc read by a person or agent (a root-wide AccessAssignment search via MCP or a script). Predicts rare, human-timed occurrences. Separating reading: the pod's request/audit log at 14:12:39Z naming the caller identity — an MCP call separates this cleanly.
  2. A shipped surface issuing the read — an access-overview page, an export, or a logon/background action that lists grants mesh-wide (the full-content select: with limit:all fits a listing/export, not a permission fold). Predicts recurrence on each invocation of that surface. Separating reading: UnanchoredQueryCensusTest's refused-set corpus (test/Memex.Portal.Shared.Test) — a core/runtime shape appears there; a plugin or ad-hoc shape does not.
  3. A core read that lost its anchor (a query built with an empty/@ base path that its author believed was pinned). Notably, the security fold's own AccessAssignment legs are anchored per-partition (SecurityQueries.PartitionAssignmentsFor) or declared (MeshWideQuery.Declare, with a reason at the call site); the observed shape matches neither, which is itself evidence that it did not come from the fold's current shapes — but a stale call site or a regression would look exactly like this. Predicts periodic recurrence tied to the owning operation. Separating reading: recurrence timing correlated against a named operation, plus the census test above.

Per Unanchored Security Reads: a genuinely mesh-wide AccessAssignment read is not freely anchorable — a share grant lives in the granting partition, and truncating the read silently drops grants and fails denials open. Whatever decides this ticket should weigh that page before following the log line's own "anchor it" advice.

Where to look

  • MeshWeaver.Plugins/src/MeshWeaver.Hosting.PostgreSql — the planner (PostgreSqlPartitionedMeshQuery), the IsSufficientlySpecified || ResolvesByRoutingHint rule, and unanchored-queries.allow (this shape is not in it)
  • Hosting/UnanchoredQueryPolicy — the refuse-in-CI / serve-and-report-in-production policy this line implements
  • UnanchoredQueryCensusTest (test/Memex.Portal.Shared.Test) — the runtime-query corpus whose refused set is asserted empty
  • SecurityQueries (src/MeshWeaver.Mesh.Contract/Security) and Granting Access via AccessAssignments — the anchored and declared shapes the fold actually issues
Evidence
Fingerprint a50cc623d41e8eb7
Category MeshWeaver.Hosting.PostgreSql.PostgreSqlPartitionedMeshQuery
Severity Error
Exception MeshWeaver.Hosting.PostgreSql.UnanchoredQueryException
Namespace memex
Pods memex-portal-deployment-c67994b85-4297g
Occurrences 1
First seen 2026-10-23 14:12:39Z
Last seen 2026-10-23 14:12:39Z
Routing not determined — no configured route matches the category MeshWeaver.Hosting.PostgreSql.PostgreSqlPartitionedMeshQuery. This repository is the configured fallback, not a finding about who owns the fault; the category names the LOGGER, which may not be the subject.
Recent log lines 
2026-10-23 14:12:39Z memex-portal-deployment-c67994b85-4297g fail: MeshWeaver.Hosting.PostgreSql.PostgreSqlPartitionedMeshQuery[0]
      [FanOut] UNANCHORED: query nodeType:AccessAssignment scope:Descendants ('path:@ scope:descendants nodeType:AccessAssignment select:path,id,namespace,name,nodeType,content limit:all') names no partition and is not listed in unanchored-queries.allow — served across every partition schema because this host runs UnanchoredQueryPolicy.ServeAndReport; a CI build refuses it. Anchor it (path:/namespace:) or declare it (partitions:all). Listing it would only lower this line to a Warning
      MeshWeaver.Hosting.PostgreSql.UnanchoredQueryException: Query is not sufficiently specified: no partition could be determined from 'path:@ scope:descendants nodeType:AccessAssignment select:path,id,namespace,name,nodeType,content limit:all'. A query without a concrete first segment would have to UNION every partition schema, which locks the whole database for every other caller. Anchor it (path:<partition>/… or namespace:<partition>/…), or request the fan-out explicitly (partitions:all — or a wildcard namespace, e.g. namespace:*/_Thread) if spanning partitions is genuinely what this read means.

This log site's previous ticket, https://github.com/Systemorph/MeshWeaver/issues/5508, was closed about a different fingerprint, and this fault fired after that close. It is left closed: an occurrence of this fingerprint is no evidence that the fault it was closed for came back. This issue now tracks the log site, and later fingerprints of it fold in here.

Opened automatically from Admin/_LogIncident/a50cc623d41e8eb7. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 3c32237f72d0a48b: other fingerprints of this site fold in here as comments rather than opening tickets of their own.

Lingua principale
C#
Stelle
12
Fork
5
Merge medio
6h 39m
PR unite (30g)
891

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Systemorph/MeshWeaver

Tutte le issue di Systemorph/MeshWeaver

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.