GitHub
08/23/2026, 1:25 PMDistributedQuery + NodeQuery row directly in its own DB transaction, bypassing queries.CreateNodeQueries — the only path that invalidated the cache. As a result, a recently cached "no pending queries" entry (5s TTL) would hide the new command from the node's next /{env}/read check-in. The node never received the query, and the short command expiration (10s default) elapsed before the cache TTL expired and the DB was finally hit.
This was especially likely when:
• The node recently checked in (priming the cache with "no pending queries")
• The operator was idle for >30s (the session freshness window), turning off acceleration and reverting the node to its normal 60s distributed_interval
Change
Added m.Queries.Cache.Invalidate(...) for the target node after the DB transaction in all four code paths that create hidden distributed queries:
• pkg/console/manager.go — SubmitCommandWithTimeout, SubmitPrimingCommand
• pkg/fileexplorer/manager.go — submitRequest, SubmitPrimingRequest
Each invalidation is guarded by m.Queries.Cache != nil so nil-cache deployments (tests, standalone mode) are unaffected. This mirrors the existing invalidation in queries.CreateNodeQueries (pkg/queries/queries.go:518).
Validation
• go test ./pkg/queries/... — includes 5 new regression tests verifying cache invalidation after console/file-explorer query creation and that the subsequent NodeQueries call finds the pending query with accelerate=true
• go test ./pkg/console/... ./pkg/fileexplorer/... — existing manager tests pass
• go test ./pkg/... ./cmd/... — full test suite passes (no regressions)
jmpsec/osctrlGitHub
08/23/2026, 2:56 PM