#942 Accelerated-mode priming for console and file explorer Pull request opened by javuto Accelerated-mode priming for console and file explorer Problem When an operator opens the node console or file explorer, accelerated query polling only engages after the user submits their first command (console) or first directory listing (file explorer). Until then the node polls at its default distributed-interval, so the first interactive command can wait a full poll cycle before it's even delivered — visible as a long "waiting for node" delay on first use. Change Open a session → immediately dispatch a hidden

osquery_info

priming query to the target node's pending distributed queue. On the node's next natural `QueryRead`: 1.

pkg/queries.NodeQueries

returns

accelerate=true

(the query type is `ConsoleQueryType`/`FileExplorerQueryType`), so the TLS handler replies with

AcceleratedQueryReadResponse{accelerate: N}

— the node switches to fast polling (default 5s) before the user types anything. 2. The priming query gets delivered and its live results (osquery version, build platform, start time, config validity, uptime) are surfaced into the session header, replacing the last-seen DB snapshot with fresh values. By the time the operator issues their first command, the node is already polling fast → near-zero timeout likelihood on the first interaction. Behavior / safety constraints • Priming never blocks user commands. `SubmitCommandWithTimeout`'s pending-count and the file explorer's pending cap both exclude

priming=true

rows, so a still-pending priming query never gates the operator's first real command. • Priming is excluded from console history (not user-issued). • Priming is non-fatal. If submission fails, the session is still returned; acceleration simply isn't pre-warmed. • Schema is additive. A

Priming

boolean column is added to

console_commands

and

file_explorer_requests

via the existing

AutoMigrate

in each

NewManager

. • Existing routes/auth wrappers are reused. The console polls the existing

GET /console/.../commands/{id}

and

/results

endpoints; the file explorer adds one new

GET /file-explorer/.../requests/{id}/metadata

route (the existing

/results

endpoint decodes file columns into

Entry

structs, so a raw-rows endpoint was needed for

osquery_info

). API changes

POST /api/v1/console/{env}/nodes/{uuid}/sessions

Response gains an optional

priming

field (

ConsoleCommand

), the priming command dispatched at session open. Frontend polls the existing command show/results endpoints with this id.

POST /api/v1/file-explorer/{env}/nodes/{uuid}/sessions

Response gains an optional

priming

field (

FileExplorerRequest

).

GET /api/v1/file-explorer/{env}/sessions/{id}/requests/{id}/metadata

(new) Returns the raw

osquery_info

rows for a priming request (generic

[]map[string]any

, unlike

/results

which decodes file columns). Frontend • NodeConsolePage — captures the priming command, polls it via

useQuery

, fetches results on completion, and renders live osquery version / build / uptime / config badges in the header. An "accelerating" spinner badge appears while priming is in flight. • NodeFileExplorerTab — same pattern via the new metadata endpoint; live metadata renders in the file explorer header next to the root path, with an "accelerating" badge while priming is in flight. Files Backend •

pkg/console/manager.go

,

pkg/console/models.go

—

PrimingMetadataSQL

,

SubmitPrimingCommand

, `PrimingCommand`; pending-count + history exclude priming •

pkg/fileexplorer/manager.go

,

pkg/fileexplorer/models.go

—

PrimingMetadataSQL

,

SubmitPrimingRequest

,

PrimingRequest

,

RequestMetadataRows

, `ActionPriming`; pending cap excludes priming •

cmd/api/handlers/console.go

— priming dispatched in

ConsoleSessionCreateHandler

,

consolePrimingTimeout

•

cmd/api/handlers/file_explorer.go

— priming dispatched in

FileExplorerSessionCreateHandler

, new

FileExplorerPrimingResultsHandler

•

cmd/api/main.go

— new metadata route Frontend •

src/api/types.ts

,

src/api/file-explorer.ts

— priming types +

getFileExplorerPrimingMetadata

•

src/features/nodes/NodeConsolePage.tsx

,

src/features/nodes/NodeFileExplorerTab.tsx

— poll + render priming Tests •

pkg/console/manager_test.go

(+4 tests),

pkg/fileexplorer/manager_test.go

(+3 tests),

cmd/api/handlers/console_test.go

(+1),

cmd/api/handlers/file_explorer_test.go

(+2) Validation •

go build ./...

— clean •

go test ./...

— all pass, including new priming tests •

golangci-lint

on touched packages — only pre-existing issues remain •

npm run check

(tsc) — clean •

npm run test

(vitest) — 190/190 pass, including existing

NodeConsolePage

(10) and

NodeFileExplorerTab

(6) suites Notes • No tests existed for the priming path before this change; new regression tests cover dispatch, non-blocking behavior, history exclusion, and result decoding for both console and file explorer. • The

Priming

column is added via

AutoMigrate

— no manual migration step is required for existing deployments. jmpsec/osctrl