Value stored in the agent_groups KV bucket, keyed by pc_id. The
wrapper struct (instead of a bare Vec<String>) leaves room for
future per-PC metadata (membership timestamps, who-set-it audit, …)
without breaking the wire format.
Per-scope partial config. Every field is Option<T>: Some =
set, None = inherit from the next-less-specific scope. Serde
default + skip_serializing_if keeps the wire JSON tight —
unset fields don’t appear in the bucket value.
Concrete config the agent runs against once the scope stack has
been flattened. target_version stays Option because “no
rollout target set anywhere” is a meaningful state (the agent
just keeps running the version it has); the other fields always
have a value, falling back to EffectiveConfig::builtin_defaults
when no scope sets them.
Lowered, engine-vocabulary form of crate::manifest::FinalizeSpec
— the post-step hook stamped onto a Command. The operator-facing
humantime timeout is reduced to whole seconds at build time
(mirrors timeout_secs), and the manifest ExecuteShell to the wire
Shell, so the agent’s fire path does no parsing.
Value stored in the group_contacts KV bucket, keyed by group name.
Holds the email addresses that should receive notifications targeted
at the group — e.g. a compliance alert’s notify_groups. Operator-
managed via the SPA Groups page, parallel to (but separate from)
agent_groups membership: membership is per-PC, contact is per-group.
Request the live tail of a single job’s output. The result_id
is the agent-minted per-PC UUID that keys execution_results, so
the SPA already has it from the Activity row / detail page.
Payload sent on logs.fetch.<pc_id> to request the tail of an
agent’s log file. Unknown / missing fields fall back to sensible
defaults so the CLI / Web UI can grow the shape later without
retraining every fleet host.
One agent tick worth of “top processes by CPU” data. processes
is already sorted (descending CPU%) and clipped to the
process_perf_top_n configured for that scope, so the backend
projector can persist it verbatim without re-sorting.
Single process row inside ProcessPerf. Mirrors the shape of
the agent’s self-perf fields on Heartbeat so existing
formatters (em-dash for nulls etc.) keep working on the SPA.
Lowered, engine-vocabulary form of crate::manifest::Retry — a
fixed-backoff retry policy stamped onto a Command. The
operator-facing humantime backoff is reduced to whole seconds at
build time (mirrors how jitter_secs / timeout_secs are
pre-lowered) so the agent’s fire path does no humantime parsing.
Value stored in the server_settings KV bucket under the single key
crate::kv::KEY_SERVER_SETTINGS. Operator-editable, backend-side
server configuration that isn’t per-agent (so it doesn’t belong in
agent_config’s layered scopes) and isn’t a fleet-wide switch every
agent watches (so it doesn’t belong in fleet_config). Managed via
the SPA Settings page’s “server settings” tab.
Non-fatal observations from resolve that the caller should
log. Currently only “two of this PC’s groups set the same field
to different values” — useful pre-emptive debugging signal when
canary / wave / dept overlays accidentally overlap.
Token + session combination the agent uses to spawn a job’s
child process. Two orthogonal axes — whose privileges and which
session — collapse into three meaningful combinations:
Built-in default for ServerSettings::check_status_stale_days (#1032②) —
how many days a check_status row may go without a fresh result before the
Compliance view treats it as stale and hides it (a PC that stopped
running a check: excluded from its target via a dynamic group, decommissioned,
or its schedule removed). 30 days is comfortably longer than a typical daily
/ weekly compliance cadence, so an in-scope PC is never mistakenly hidden,
while a genuinely out-of-scope PC’s frozen row drops out within the month.
A real default (like collect_retention_days) so the feature works out of
the box; the operator shortens it for prompter hiding or sets 0 to disable.
Built-in retention window (days) for the collections Object Store —
the file bundles a collect: job uploads (#219). This is the value the
bootstrap creates a fresh bucket with, and the fallback
ServerSettings::effective_collect_retention_days resolves to when the
operator hasn’t overridden it. Kept here (not just in bootstrap) so the
wire default and the bucket’s initial max_age share one source of truth.
Built-in default for ServerSettings::session_ttl_hours — how long a
freshly-minted SPA/CLI login token stays valid when the operator hasn’t
overridden it. 24h balances “don’t re-auth mid-workday” against a
bounded window for a leaked token (the DB row is re-checked every
request, so disable still takes effect immediately regardless).
Built-in default for SupportCode::ttl_minutes — how long an unlock
grant lasts when the operator hasn’t set a per-code window. 15 minutes is
about the length of a helpdesk call: long enough that the desk isn’t
re-typing the code mid-troubleshoot, short enough that a machine left
unattended after the call re-locks on its own.
Synthetic exit code for a run the agent skipped because the
Command’s version didn’t match the script_current pin. One of
the four reserved skip codes (124–127): the agent publishes a
normal ExecResult so the operator can see why nothing ran,
but the script itself never executed — consumers that derive state
from a run’s output (e.g. the backend’s check_status projection)
must treat these as “no new evidence”, not as a run (#909).
Upper bound on ServerSettings::agent_prune_days (100 years). A
value this large already means “effectively never”, and it keeps the
cleanup task’s now - Duration::days(n) subtraction comfortably inside
chrono::DateTime’s representable range — DateTime - Duration panics
on overflow, and an unbounded u32 (~11.7 M years) would trip it.
Enforced two ways: the PUT handler rejects a larger value, and
ServerSettings::effective_agent_prune_days clamps to it so even a
hand-written KV value can never panic the cleanup task.
Upper bound on ServerSettings::check_status_stale_days (10 years).
Staleness is purely a display cutoff (now - Duration::days(n) compared to a
row’s recorded_at), so the ceiling just keeps that subtraction inside
chrono::DateTime’s range and stops an absurd value; enforced by the PUT
handler and clamped in ServerSettings::effective_check_status_stale_days.
Upper bound on ServerSettings::collect_retention_days (10 years).
Bundles are debugging / audit artifacts, so an operator has no reason to
keep them longer than this; the ceiling stops a fat-fingered value from
pushing the collections Object Store’s max_age to something absurd.
(The bucket’s max_bytes cap still bounds actual disk regardless.)
Enforced by the PUT handler and clamped in
ServerSettings::effective_collect_retention_days so even a
hand-written KV value stays sane.
Upper bound on ServerSettings::session_ttl_hours (365 days). Keeps
login’s Utc::now() + Duration::hours(n) comfortably inside chrono’s
representable range (its nanosecond i64 caps out ~292 years, so an
unclamped u32 of hours could overflow) and stops an operator pinning a
practically-immortal session. Enforced by the PUT handler and clamped in
ServerSettings::effective_session_ttl_hours so even a hand-written
KV value stays bounded.
Upper bound on SupportCode::ttl_minutes (8 hours). An unlock grant is
standing permission for an end user’s machine to run privileged jobs, so
it must not outlive a working day even by operator error — a longer window
is a visible_to targeting decision, not an unlock one. Enforced by the
support-code endpoint and clamped in SupportCode::effective_ttl_minutes
so a hand-written KV value stays bounded too.
Headers for a gap message. The reason travels as the payload, not a
header, because it is free text of unbounded length and headers are a
poor place for that.
True when exit_code is one of the reserved synthetic skip codes
(124–127) — the agent published this result instead of running
the script, so it carries no evidence about the script’s outcome.