kanade_shared/kv.rs
1//! NATS KV bucket name + key helpers (spec §2.3.2).
2//!
3//! NATS KV bucket names must be domain-safe ASCII (a-z, A-Z, 0-9, _, -),
4//! so the spec's dotted names (`script.current`, `script.status`) are
5//! flattened to underscore form here.
6
7pub const BUCKET_SCRIPT_CURRENT: &str = "script_current";
8pub const BUCKET_SCRIPT_STATUS: &str = "script_status";
9pub const BUCKET_AGENTS_STATE: &str = "agents_state";
10pub const BUCKET_AGENT_CONFIG: &str = "agent_config";
11pub const BUCKET_AGENT_GROUPS: &str = "agent_groups";
12
13/// `group_contacts` — per-group notification email addresses, keyed by
14/// group name, value JSON [`GroupContacts`](crate::wire::GroupContacts).
15/// Operator-managed via the SPA Groups page. Distinct from
16/// `agent_groups` (per-PC membership) and `agent_config`'s `groups.*`
17/// scopes (agent config pushed to machines): this is operator contact
18/// info, read backend-side to fan a compliance alert out to email.
19pub const BUCKET_GROUP_CONTACTS: &str = "group_contacts";
20
21pub const BUCKET_SCHEDULES: &str = "schedules";
22
23/// Job catalog (v0.15) — operator-registered Manifests, keyed by
24/// `manifest.id`. Schedules and ad-hoc `kanade run --job-id ...` look
25/// jobs up here; the wire never round-trips an inline Manifest body
26/// through a Schedule again. Editing a job in-place retroactively
27/// changes what future schedule fires deploy.
28pub const BUCKET_JOBS: &str = "jobs";
29
30/// Parallel "operator source-of-truth YAML" stores keyed identically
31/// to `BUCKET_JOBS` / `BUCKET_SCHEDULES`. The agent / scheduler /
32/// projector all keep reading the JSON KVs above — these buckets
33/// exist only so the SPA's YAML editor can round-trip operator
34/// comments + script indentation + block-scalar style exactly.
35///
36/// Population is opportunistic: any `POST` with a
37/// `Content-Type: application/yaml` body stores the raw bytes here
38/// alongside the parsed JSON; JSON-content-type POSTs fall back to a
39/// `serde_yaml` dump so the buckets stay in lockstep with the JSON
40/// store (operator just loses comments on that path).
41pub const BUCKET_JOBS_YAML: &str = "jobs_yaml";
42pub const BUCKET_SCHEDULES_YAML: &str = "schedules_yaml";
43
44/// View catalog (#743) — operator-registered [`View`](crate::manifest::View)
45/// resources, keyed by `view.id`. A view is a pure, declarative
46/// read/aggregation over stored fleet data (`obs_events`, …) for the
47/// Analytics page — no `execute`, no schedule. The backend reads these at
48/// query time and merges their widgets with the co-located `aggregate:`
49/// hints on jobs. Distinct from `BUCKET_JOBS` so a cross-cutting dashboard
50/// doesn't need a noop job carrier.
51pub const BUCKET_VIEWS: &str = "views";
52/// Operator source-of-truth YAML mirror for `BUCKET_VIEWS` (same role as
53/// `BUCKET_JOBS_YAML`): keeps comments/formatting for the SPA editor.
54pub const BUCKET_VIEWS_YAML: &str = "views_yaml";
55
56/// Fleet-wide singleton settings that aren't per-agent (so they don't
57/// belong in `agent_config`'s layered scopes) and aren't per-schedule
58/// (so they don't belong in `schedules`). First and only key so far is
59/// [`KEY_FREEZE`] (#418 Phase 5 global change-freeze). One small bucket
60/// both the backend scheduler and every agent's local scheduler watch.
61pub const BUCKET_FLEET_CONFIG: &str = "fleet_config";
62
63/// Backend-side, operator-editable server settings that aren't per-agent
64/// (so they don't belong in `agent_config`'s layered scopes) and aren't a
65/// fleet-wide switch every agent watches (so they don't belong in
66/// `fleet_config`). A single JSON document under [`KEY_SERVER_SETTINGS`]
67/// holding [`crate::wire::ServerSettings`], managed via the SPA Settings
68/// page's "server settings" tab. Deliberately generic: future server-side
69/// knobs join the same document rather than spawning a bucket each. First
70/// consumer is the cleanup task's dead-agent prune window
71/// (`ServerSettings::agent_prune_days`). `history: 1` — only the current
72/// state matters; nothing replays its history.
73pub const BUCKET_SERVER_SETTINGS: &str = "server_settings";
74
75/// Singleton key in [`BUCKET_SERVER_SETTINGS`] holding the JSON-encoded
76/// [`crate::wire::ServerSettings`]. **Key absent ⇒ all-default settings**
77/// (e.g. `agent_prune_days = 0`, pruning disabled), so a fresh deployment
78/// behaves exactly as it did before the bucket existed.
79pub const KEY_SERVER_SETTINGS: &str = "current";
80
81/// `notifications_read` — per-user read/ack state for end-user
82/// notifications (SPEC §2.3.2 / Phase E). Key shape
83/// `{pc_id}.{user_sid}.{notification_id}`, value JSON
84/// `{"acked_at": ..., "acked_by": "<sid>"}`. The agent writes a row
85/// when it handles a KLP `notifications.ack`, stamping the connecting
86/// user's OS-derived SID — so a shared PC tracks each user's reads
87/// independently. The `{pc_id}.{user_sid}.` prefix lets
88/// `notifications.list` fetch one user's read set with a single prefix
89/// walk. `history: 1` — only the latest ack per key matters.
90pub const BUCKET_NOTIFICATIONS_READ: &str = "notifications_read";
91
92/// KV key in [`BUCKET_NOTIFICATIONS_READ`] for one user's ack of one
93/// notification: `{pc_id}.{user_sid}.{notification_id}` (SPEC §2.3.2).
94///
95/// The components are joined with `.` per the spec's documented key
96/// shape. In practice none of them contain a `.` — `pc_id` is a
97/// hostname, `user_sid` is `S-1-5-…` (hyphen-delimited), and the
98/// backend mints `notification_id` as a UUID (operator-supplied
99/// manifest ids are kebab-case) — so the join stays unambiguous and
100/// the `{pc_id}.{user_sid}.` prefix (see
101/// [`notifications_read_prefix`]) cleanly selects exactly one user's
102/// read set for `notifications.list`.
103pub fn notifications_read_key(pc_id: &str, user_sid: &str, notification_id: &str) -> String {
104 format!("{pc_id}.{user_sid}.{notification_id}")
105}
106
107/// Prefix selecting every ack row for one `(pc_id, user_sid)` in
108/// [`BUCKET_NOTIFICATIONS_READ`] — `{pc_id}.{user_sid}.`.
109/// `notifications.list` walks the bucket keys and keeps those carrying
110/// this prefix to compute the caller's unread set. Pairs with
111/// [`notifications_read_key`].
112pub fn notifications_read_prefix(pc_id: &str, user_sid: &str) -> String {
113 format!("{pc_id}.{user_sid}.")
114}
115
116/// Singleton key in [`BUCKET_FLEET_CONFIG`] holding the JSON-encoded
117/// [`crate::manifest::Freeze`]. **Key absent ⇒ not frozen** (clearing
118/// the freeze is a KV delete), so readers treat a missing key as "fire
119/// normally" and only evaluate `Freeze::is_active` when the key exists.
120pub const KEY_FREEZE: &str = "freeze";
121
122/// KV bucket holding **per-(schedule, pc) last-dispatch marks** for the
123/// backend scheduler's in-flight suppression.
124///
125/// The per-pc / per-target dedup ([`crate::manifest::ExecMode`]) only
126/// sees *completed* runs (`execution_results`, exit_code = 0). Since
127/// #418 the reconcile poll runs every minute ([`crate::manifest::POLL_CRON`]),
128/// but a dispatched Command doesn't land a completion until
129/// `jitter (agent-side) + run + outbox drain` later — frequently
130/// several minutes with a 3–5 min jitter. Without a dispatch record the
131/// poll re-fires the same PC (or whole target) every tick across that
132/// gap. This bucket records "I dispatched (schedule, pc) at T" so the
133/// scheduler can suppress re-fire for a bounded window without waiting
134/// on the completion round-trip.
135///
136/// Values are the dispatch instant as an RFC3339 string. A bucket-wide
137/// `max_age` GCs marks once they're well past any suppression window,
138/// so the bucket can't grow unbounded; the suppression-window check
139/// itself lives in `scheduler::policy::suppress_dispatched`.
140pub const BUCKET_SCHEDULER_DISPATCH: &str = "scheduler_dispatch";
141
142/// Per-pc dispatch-mark key (OncePerPc).
143///
144/// The `pc.` / `target.` kind prefix keeps the two namespaces apart,
145/// and each component is **length-prefixed** (`<len>.<value>`) so no two
146/// distinct `(schedule_id, pc_id)` pairs can ever collide — even when an
147/// id contains the `.` separator: `("a.b", "c")` → `pc.3.a.b.1.c`,
148/// `("a", "b.c")` → `pc.1.a.3.b.c`. (Percent-/base64-encoding isn't an
149/// option: NATS KV keys only allow `[-/_=.a-zA-Z0-9]`, so the
150/// self-delimiting length prefix is the cheapest injective encoding that
151/// stays in-charset.)
152pub fn dispatch_mark_pc_key(schedule_id: &str, pc_id: &str) -> String {
153 format!(
154 "pc.{}.{}.{}.{}",
155 schedule_id.len(),
156 schedule_id,
157 pc_id.len(),
158 pc_id
159 )
160}
161
162/// Whole-target dispatch-mark key (OncePerTarget). One key per
163/// schedule — a per-target fire dispatches the whole target at once, so
164/// there's nothing per-pc to record. Length-prefixed for symmetry with
165/// [`dispatch_mark_pc_key`].
166pub fn dispatch_mark_target_key(schedule_id: &str) -> String {
167 format!("target.{}.{}", schedule_id.len(), schedule_id)
168}
169
170/// Object Store bucket holding raw agent binaries (one object per
171/// version, e.g. `0.2.0` → file bytes).
172pub const OBJECT_AGENT_RELEASES: &str = "agent_releases";
173
174/// Object Store holding **generic application packages** — anything
175/// the agent / kitting scripts pull down + install on endpoints.
176/// First consumer is the kanade-client app, but the bucket is
177/// intentionally generic: third-party installers (Webex, Teams,
178/// custom MSI bundles), upgrade scripts, configuration archives,
179/// etc. all live here.
180///
181/// Object keys are `<name>/<version>` — operator picks `<name>`
182/// once per package family (e.g. `kanade-client`,
183/// `webex-meetings`), then `<version>` per release (e.g.
184/// `0.41.0`, `2025.03`). Slashes are explicitly allowed by NATS
185/// Object Store key rules; the SPA / CLI / HTTP routes all carry
186/// the pair as two path segments.
187///
188/// Why a separate bucket from `agent_releases`:
189/// - `agent_releases` is fleet-critical (the agent's own self-
190/// update path). Keeping it small + audited matters.
191/// - `app_packages` is operator-curated user-space content. The
192/// lifecycle is different (operators add/remove packages
193/// freely; agent releases follow the release.yml pipeline).
194pub const OBJECT_APP_PACKAGES: &str = "app_packages";
195
196/// Object Store holding **manifest script bodies** referenced by
197/// `Execute::script_object` (SPEC §2.4.1's alternative to inline
198/// `script:` / repo-local `script_file:`). Per yukimemi/kanade
199/// issue #210, this is the "Plan B 4-bucket layout" sibling of
200/// `app_packages` — separated because scripts have a different
201/// lifecycle than installer binaries:
202///
203/// - Smaller (typical KB-to-low-MB, vs MB-to-hundreds-of-MB
204/// installers).
205/// - Coupled to manifest versions (script lifecycle = manifest
206/// lifecycle; the `script_current` / `script_status` KV gates
207/// in SPEC §2.6.2 already track manifest versions, so a
208/// matching dedicated bucket keeps the audit story aligned).
209/// - Different access pattern (every Command execute potentially
210/// fetches; vs installer fetched once per fleet deploy).
211///
212/// Object keys follow the same `<name>/<version>` shape as
213/// `app_packages` so the SPA / operator tooling stays uniform.
214/// For manifest-driven scripts `<name>` is the manifest id and
215/// `<version>` is the manifest version, but the bucket itself
216/// imposes no semantics on the pair — operator-uploaded
217/// ad-hoc scripts can use any `<name>/<version>` they like.
218pub const OBJECT_SCRIPTS: &str = "scripts";
219
220/// Object Store holding **overflow stdout / stderr blobs** for the
221/// `ExecResult` wire kind (#227). The default NATS `max_payload` is
222/// 1 MB; a result whose stdout / stderr exceeds it would reject the
223/// publish and pin the agent's outbox in a reconnect loop. The agent
224/// uploads any stdout / stderr larger than `STDOUT_INLINE_THRESHOLD`
225/// (256 KB, picked at 1/4 of the default max_payload so the rest of
226/// the ExecResult fields fit alongside) into this bucket and replaces
227/// the inline field with [`crate::wire::ExecResult::stdout_object`] /
228/// `stderr_object` pointers. Backend's results projector derefs the
229/// pointers before INSERT so downstream consumers (SQLite, SPA
230/// Activity, inventory projector) see the full text the same way
231/// they always have.
232///
233/// Object keys follow the shape `<request_id>/{stdout,stderr}` so
234/// stdout + stderr for the same execution share a sibling prefix —
235/// makes `kanade jetstream` listings group naturally and keeps the
236/// per-key namespace tight against duplicate uploads.
237///
238/// Per-bucket retention (not a stream-wide TTL since async-nats
239/// object_store inherits stream config): matches `STREAM_RESULTS`'s
240/// 30-day retention so an operator who can still query the result
241/// row in SQLite can also fetch the original blob if the inline
242/// copy ever needs re-projection.
243pub const OBJECT_RESULT_OUTPUT: &str = "result_output";
244
245/// Object Store holding **collected file bundles** (#219). A job
246/// carrying a `collect:` manifest hint prints a JSON list of file
247/// paths on stdout; the agent zips them and uploads the archive here,
248/// recording the key in [`crate::wire::ExecResult::collect_object`].
249/// The SPA Collect page lists / downloads bundles straight from this
250/// bucket. Object keys follow `<pc_id>/<job_id>/<rfc3339>.zip`, or
251/// `<pc_id>/<job_id>/<label>__<rfc3339>.zip` when a run emits multiple
252/// labeled bundles (e.g. one zip per day), so a listing groups by host
253/// then job. Per-bucket retention is 30 days
254/// (bundles are debugging/audit artifacts, not curated config like
255/// `app_packages` / `scripts`, so they auto-expire) — see
256/// `kanade-shared::bootstrap`.
257pub const OBJECT_COLLECTIONS: &str = "collections";
258
259/// Inline threshold for `ExecResult.stdout` / `.stderr`. Larger
260/// payloads overflow into [`OBJECT_RESULT_OUTPUT`]. 256 KB = 1/4 of
261/// the NATS default `max_payload` (1 MB) so the rest of the
262/// ExecResult JSON (request_id, exec_id, etc.) easily fits below the
263/// publish-reject ceiling.
264///
265/// Lives next to the bucket constant rather than on the agent side
266/// so the SPA / future operator tooling can quote the same threshold
267/// when explaining "why this result has no inline stdout".
268pub const STDOUT_INLINE_THRESHOLD: usize = 256 * 1024;
269
270/// Key inside [`BUCKET_AGENT_CONFIG`] carrying the broadcast target
271/// version. Agents watch this key and self-update when their running
272/// version drifts.
273pub const KEY_AGENT_TARGET_VERSION: &str = "target_version";
274
275/// Sprint 6 layered-config keys inside [`BUCKET_AGENT_CONFIG`]:
276/// * `global` — fleet-wide default ConfigScope JSON
277/// * `groups.<name>` — per-group override (partial ConfigScope)
278/// * `pcs.<pc_id>` — per-pc override (partial ConfigScope)
279///
280/// The `groups.` / `pcs.` prefixes let a `kv.keys()` walk pick out
281/// just the rows in one scope when listing.
282pub const KEY_AGENT_CONFIG_GLOBAL: &str = "global";
283pub const PREFIX_AGENT_CONFIG_GROUPS: &str = "groups.";
284pub const PREFIX_AGENT_CONFIG_PCS: &str = "pcs.";
285
286pub fn agent_config_group_key(group: &str) -> String {
287 format!("{PREFIX_AGENT_CONFIG_GROUPS}{group}")
288}
289
290pub fn agent_config_pc_key(pc_id: &str) -> String {
291 format!("{PREFIX_AGENT_CONFIG_PCS}{pc_id}")
292}
293
294/// Inverse of [`agent_config_group_key`] — returns the bare group
295/// name if `key` carries the groups-scope prefix, else `None`.
296pub fn parse_agent_config_group_key(key: &str) -> Option<&str> {
297 key.strip_prefix(PREFIX_AGENT_CONFIG_GROUPS)
298}
299
300/// Inverse of [`agent_config_pc_key`].
301pub fn parse_agent_config_pc_key(key: &str) -> Option<&str> {
302 key.strip_prefix(PREFIX_AGENT_CONFIG_PCS)
303}
304
305pub const SCRIPT_STATUS_ACTIVE: &str = "ACTIVE";
306pub const SCRIPT_STATUS_REVOKED: &str = "REVOKED";
307
308pub const STREAM_INVENTORY: &str = "INVENTORY";
309pub const STREAM_RESULTS: &str = "RESULTS";
310pub const STREAM_EXEC: &str = "EXEC";
311pub const STREAM_EVENTS: &str = "EVENTS";
312pub const STREAM_AUDIT: &str = "AUDIT";
313
314/// JetStream stream retaining end-user notification history (SPEC
315/// §2.3.1 / Phase E). Catches every `notifications.{all|group.X|pc.Y}`
316/// publish the backend fans out, so a Client App that connects after
317/// a notification was sent can still fetch it via KLP
318/// `notifications.list`. 90-day window — long enough for "what did I
319/// miss while on leave" without unbounded growth. Unlike `EXEC`,
320/// retains all messages per subject (no `max_messages_per_subject`):
321/// each notification is its own history entry, not a latest-only state.
322pub const STREAM_NOTIFICATIONS: &str = "NOTIFICATIONS";
323
324/// JetStream stream backing the per-PC observability event pipeline
325/// (Issue #246). Distinct from [`STREAM_EVENTS`] (in-flight script
326/// lifecycle) — `STREAM_OBS_EVENTS` carries the timeline data the
327/// SPA's Events page consumes: sign-in/out, power on/off, sleep/
328/// resume, agent milestones, diagnostic bundle pointers. The agent
329/// publishes on `obs.<pc_id>` (see [`crate::subject::obs`]) and
330/// this stream catches everything matching [`crate::subject::OBS_FILTER`]
331/// so a backend that boots after the agent doesn't miss any
332/// already-emitted events.
333pub const STREAM_OBS_EVENTS: &str = "OBS_EVENTS";
334
335/// Canonical list of every JetStream resource
336/// [`crate::bootstrap::ensure_jetstream_resources`] creates. The health
337/// rollup (`/api/health/fleet`) and the status snapshot
338/// (`/api/jetstream/status`) both iterate these so the dashboard reports
339/// the *complete* resource set — previously each kept its own hand-
340/// maintained subset that drifted behind bootstrap (e.g. only 1 of the 5
341/// object stores showed up). Keep in lockstep with `bootstrap.rs`: a new
342/// stream / bucket / store added there must be appended here too. The
343/// `canonical_resource_lists_are_sane` test below guards the easy
344/// mistakes (dots, dupes, empties); keeping the *set* aligned with
345/// bootstrap stays a manual discipline (bootstrap needs per-resource
346/// config, so it can't be derived from a name list alone).
347pub const ALL_STREAMS: &[&str] = &[
348 STREAM_INVENTORY,
349 STREAM_RESULTS,
350 STREAM_EXEC,
351 STREAM_EVENTS,
352 STREAM_AUDIT,
353 STREAM_OBS_EVENTS,
354 STREAM_NOTIFICATIONS,
355];
356
357/// Every KV bucket `ensure_jetstream_resources` creates. The `*_yaml`
358/// source-of-truth buckets and the operator-managed singletons
359/// (`fleet_config`, `group_contacts`) are included — they're part of the
360/// bootstrap contract, so a missing one is a genuine degradation. Lazily-
361/// created buckets that bootstrap does NOT guarantee (e.g. `views`,
362/// `scheduler_dispatch`) are deliberately excluded so a fresh fleet that
363/// never used them doesn't read as degraded.
364pub const ALL_KV_BUCKETS: &[&str] = &[
365 BUCKET_SCRIPT_CURRENT,
366 BUCKET_SCRIPT_STATUS,
367 BUCKET_AGENTS_STATE,
368 BUCKET_AGENT_CONFIG,
369 BUCKET_AGENT_GROUPS,
370 BUCKET_GROUP_CONTACTS,
371 BUCKET_SCHEDULES,
372 BUCKET_JOBS,
373 BUCKET_FLEET_CONFIG,
374 BUCKET_NOTIFICATIONS_READ,
375 BUCKET_JOBS_YAML,
376 BUCKET_SCHEDULES_YAML,
377];
378
379/// Every Object Store `ensure_jetstream_resources` creates. The status
380/// probe used to list only `agent_releases`, which is why the dashboard's
381/// "Object stores" column looked suspiciously empty.
382pub const ALL_OBJECT_STORES: &[&str] = &[
383 OBJECT_AGENT_RELEASES,
384 OBJECT_APP_PACKAGES,
385 OBJECT_SCRIPTS,
386 OBJECT_RESULT_OUTPUT,
387 OBJECT_COLLECTIONS,
388];
389
390#[cfg(test)]
391mod tests {
392 use super::*;
393
394 /// NATS KV bucket names must be domain-safe ASCII (a-z, A-Z, 0-9, _, -).
395 /// Lock the constants down so a future edit doesn't introduce a `.` and
396 /// break create_key_value silently on the broker side.
397 #[test]
398 fn bucket_names_are_domain_safe() {
399 for name in [
400 BUCKET_SCRIPT_CURRENT,
401 BUCKET_SCRIPT_STATUS,
402 BUCKET_AGENTS_STATE,
403 BUCKET_AGENT_CONFIG,
404 BUCKET_AGENT_GROUPS,
405 BUCKET_GROUP_CONTACTS,
406 BUCKET_SCHEDULES,
407 BUCKET_JOBS,
408 BUCKET_JOBS_YAML,
409 BUCKET_SCHEDULES_YAML,
410 BUCKET_VIEWS,
411 BUCKET_VIEWS_YAML,
412 BUCKET_FLEET_CONFIG,
413 BUCKET_SERVER_SETTINGS,
414 BUCKET_NOTIFICATIONS_READ,
415 BUCKET_SCHEDULER_DISPATCH,
416 OBJECT_AGENT_RELEASES,
417 OBJECT_APP_PACKAGES,
418 OBJECT_SCRIPTS,
419 OBJECT_RESULT_OUTPUT,
420 OBJECT_COLLECTIONS,
421 ] {
422 assert!(
423 !name.contains('.'),
424 "bucket name {name:?} contains a dot, which NATS KV rejects"
425 );
426 assert!(
427 name.chars()
428 .all(|c| c.is_ascii_alphanumeric() || c == '_' || c == '-'),
429 "bucket name {name:?} has non-domain-safe characters"
430 );
431 }
432 }
433
434 #[test]
435 fn stream_names_are_unique() {
436 let names = [
437 STREAM_INVENTORY,
438 STREAM_RESULTS,
439 STREAM_EXEC,
440 STREAM_EVENTS,
441 STREAM_AUDIT,
442 STREAM_OBS_EVENTS,
443 STREAM_NOTIFICATIONS,
444 ];
445 let mut deduped = names.to_vec();
446 deduped.sort_unstable();
447 deduped.dedup();
448 assert_eq!(
449 deduped.len(),
450 names.len(),
451 "stream constants collide: {names:?}"
452 );
453 }
454
455 /// The canonical lists the health + status probes iterate must be
456 /// non-empty, dup-free, and domain-safe (the same charset rule the
457 /// broker enforces). Catches a copy-paste dupe or a stray `.` before
458 /// it turns into a phantom "missing resource" on the dashboard.
459 #[test]
460 fn canonical_resource_lists_are_sane() {
461 for (label, list) in [
462 ("ALL_STREAMS", ALL_STREAMS),
463 ("ALL_KV_BUCKETS", ALL_KV_BUCKETS),
464 ("ALL_OBJECT_STORES", ALL_OBJECT_STORES),
465 ] {
466 assert!(!list.is_empty(), "{label} is empty");
467 let mut deduped = list.to_vec();
468 deduped.sort_unstable();
469 deduped.dedup();
470 assert_eq!(
471 deduped.len(),
472 list.len(),
473 "{label} has duplicates: {list:?}"
474 );
475 for name in list {
476 assert!(
477 name.chars()
478 .all(|c| c.is_ascii_alphanumeric() || c == '_' || c == '-'),
479 "{label} entry {name:?} has non-domain-safe characters"
480 );
481 }
482 }
483 }
484
485 #[test]
486 fn notifications_read_key_and_prefix_align() {
487 let key = notifications_read_key("PC1234", "S-1-5-21-1001", "notif-9f3a");
488 assert_eq!(key, "PC1234.S-1-5-21-1001.notif-9f3a");
489 let prefix = notifications_read_prefix("PC1234", "S-1-5-21-1001");
490 assert_eq!(prefix, "PC1234.S-1-5-21-1001.");
491 // The list path selects a user's read set by this prefix — the
492 // key for any of that user's notifications must carry it.
493 assert!(key.starts_with(&prefix));
494 // A different user's key must NOT match the prefix.
495 let other = notifications_read_key("PC1234", "S-1-5-21-1002", "notif-9f3a");
496 assert!(!other.starts_with(&prefix));
497 }
498
499 #[test]
500 fn script_status_strings() {
501 assert_eq!(SCRIPT_STATUS_ACTIVE, "ACTIVE");
502 assert_eq!(SCRIPT_STATUS_REVOKED, "REVOKED");
503 assert_ne!(SCRIPT_STATUS_ACTIVE, SCRIPT_STATUS_REVOKED);
504 }
505
506 #[test]
507 fn key_agent_target_version_constant() {
508 assert_eq!(KEY_AGENT_TARGET_VERSION, "target_version");
509 }
510
511 #[test]
512 fn agent_config_group_key_round_trips() {
513 let k = agent_config_group_key("canary");
514 assert_eq!(k, "groups.canary");
515 assert_eq!(parse_agent_config_group_key(&k), Some("canary"));
516 }
517
518 #[test]
519 fn agent_config_pc_key_round_trips() {
520 let k = agent_config_pc_key("PC-01");
521 assert_eq!(k, "pcs.PC-01");
522 assert_eq!(parse_agent_config_pc_key(&k), Some("PC-01"));
523 }
524
525 #[test]
526 fn dispatch_mark_keys_are_distinct_by_kind() {
527 // The whole-target key for one schedule must never equal the
528 // per-pc key for another — the `pc.` / `target.` prefixes keep
529 // the two namespaces apart even when ids look alike.
530 let per_pc = dispatch_mark_pc_key("collect-winlog-events", "PC-01");
531 let target = dispatch_mark_target_key("collect-winlog-events");
532 assert_eq!(per_pc, "pc.21.collect-winlog-events.5.PC-01");
533 assert_eq!(target, "target.21.collect-winlog-events");
534 assert_ne!(per_pc, target);
535 // A schedule literally named "collect-winlog-events.PC-01"
536 // still can't collide with the per-pc key above.
537 assert_ne!(
538 dispatch_mark_target_key("collect-winlog-events.PC-01"),
539 per_pc,
540 );
541 }
542
543 #[test]
544 fn dispatch_mark_pc_key_has_no_dot_collision() {
545 // Length-prefixing makes the encoding injective: a dotted
546 // schedule_id can't borrow a leading segment from the pc_id (or
547 // vice versa) to forge a colliding key. (CodeRabbit / claude #444.)
548 assert_ne!(
549 dispatch_mark_pc_key("a.b", "c"),
550 dispatch_mark_pc_key("a", "b.c"),
551 );
552 assert_ne!(
553 dispatch_mark_pc_key("x", "y.z"),
554 dispatch_mark_pc_key("x.y", "z"),
555 );
556 // Same components, swapped roles — also distinct.
557 assert_ne!(
558 dispatch_mark_pc_key("foo", "bar"),
559 dispatch_mark_pc_key("bar", "foo"),
560 );
561 }
562
563 #[test]
564 fn agent_config_scope_keys_do_not_collide() {
565 // Belt + braces: make sure no pc id starting with "groups." would
566 // be misparsed (or vice versa). The prefixes are distinct because
567 // they each end in `.` and the parent buckets disagree on what
568 // comes after — pcs holds host names, groups holds membership
569 // names — but locking the invariant in a test stops a future
570 // rename from breaking it.
571 assert_ne!(PREFIX_AGENT_CONFIG_GROUPS, PREFIX_AGENT_CONFIG_PCS);
572 assert!(parse_agent_config_group_key("pcs.someone").is_none());
573 assert!(parse_agent_config_pc_key("groups.someone").is_none());
574 assert_eq!(parse_agent_config_group_key("global"), None);
575 assert_eq!(parse_agent_config_pc_key("global"), None);
576 }
577}