Answer AST name queries for pdbmux_source on /facts #30
Reference in New Issue
Block a user
Delete Branch "benvin/pdbmux-source-fact-ast"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
/factsAST queries namingpdbmux_source(node-lookup-F, puppetboard inventory) are fanned out as-is, and no backend holds that fact, so they return nothing while the/facts/pdbmux_sourcepath works.=/~/in-array name comparison matches it=/~/inon certname/environment/name/value locallyX-BackendsserveSourceFacts.sourceFacts(ctx, ..., nil)fans out an unfiltered whole-estate/factson every request (facts are never cached), even for a single-host query like["and",["=","certname","h1"],["=","name","pdbmux_source"]]; the drilldown it replaces narrows byparams→ pass the query's top-levelandcertname/environment conjuncts as the second fetch's query.X-Backendscounts only the first fetch'salive; a backend lost during the line-411 fetch silently drops its nodes' synthetic records while the header still says 2/2 → count the smaller of the two alive sets.ponytail:comment is wrong:["not",["=","name","pdbmux_source"]]is selected (namesFact descends intonot); the real gap is["not",["=","name","osfamily"]]returning no synthetic records → reword.nit: source.go:259 —
namesFactdescends intonot, so["not",["=","name","pdbmux_source"]]is taken as selecting the fact: it adds an unscoped whole-estate/factsfetch (and can dropX-Backends) for a query that never returns a synthetic record → stop descending intonot(onlyand/or).