kanade_shared/subject.rs
1pub const COMMANDS_ALL: &str = "commands.all";
2
3pub fn commands_group(name: &str) -> String {
4 format!("commands.group.{name}")
5}
6
7pub fn commands_pc(pc_id: &str) -> String {
8 format!("commands.pc.{pc_id}")
9}
10
11/// `notifications.all` — broadcast end-user notification (SPEC
12/// §2.2.1 / Phase E). Mirrors [`COMMANDS_ALL`] but on the
13/// notification fan-out plane: the backend publishes here, the
14/// `NOTIFICATIONS` stream retains it, and every agent forwards it to
15/// the Client Apps in matching user sessions.
16pub const NOTIFICATIONS_ALL: &str = "notifications.all";
17
18/// Subject prefix for [`notifications_group`]. Exposed so callers that
19/// parse a subject back into its group name (the backend's notification
20/// audience resolver) strip against the same string the builder emits —
21/// if the format ever changes, both move together instead of the parser
22/// silently failing to match.
23pub const NOTIFICATIONS_GROUP_PREFIX: &str = "notifications.group.";
24
25/// Subject prefix for [`notifications_pc`]. See
26/// [`NOTIFICATIONS_GROUP_PREFIX`].
27pub const NOTIFICATIONS_PC_PREFIX: &str = "notifications.pc.";
28
29/// `notifications.group.{group_name}` — group-scoped end-user
30/// notification. Sibling of [`commands_group`] on the notification
31/// plane.
32pub fn notifications_group(name: &str) -> String {
33 format!("{NOTIFICATIONS_GROUP_PREFIX}{name}")
34}
35
36/// `notifications.pc.{pc_id}` — single-PC end-user notification.
37/// Sibling of [`commands_pc`] on the notification plane.
38pub fn notifications_pc(pc_id: &str) -> String {
39 format!("{NOTIFICATIONS_PC_PREFIX}{pc_id}")
40}
41
42/// `notif-amend` — ephemeral fleet-wide control channel for post-send
43/// operations on a notification (currently: recall). Deliberately NOT
44/// under `notifications.>` so the `NOTIFICATIONS` JetStream stream doesn't
45/// retain it (these are live control pushes, not history). Published via
46/// **core NATS** (fire-and-forget); every agent subscribes and forwards a
47/// `notifications.amended` push to its clients, each of which applies it
48/// only if it holds the referenced id — so a single broadcast needs no
49/// per-audience routing (an id a client doesn't have is a no-op). The
50/// durable half of a recall is the stream message deletion; this is just
51/// the "remove it from screens that are showing it now" half.
52pub const NOTIFICATIONS_AMEND_SUBJECT: &str = "notif-amend";
53
54/// `events.notifications.acked.{pc_id}.{user_sid}.{notif_id}` — the
55/// agent publishes this when a user clicks "確認" on a notification
56/// (SPEC §2.2.2 / Phase E). The `{user_sid}` segment distinguishes
57/// concurrent users on a shared PC (Fast User Switching / RDP). Lives
58/// under `events.>` so the existing `EVENTS` stream retains it; the
59/// backend's notification-acks projector consumes the narrowed
60/// [`EVENTS_NOTIFICATIONS_ACKED_FILTER`] to build the SPA's
61/// per-recipient confirmation view.
62///
63/// Subject spelling is fixed by SPEC §2.2.2 / §2.12.8 (`events.>`), so
64/// acks ride the `EVENTS` stream's retention (shorter than the 90-day
65/// `NOTIFICATIONS` history), not the notification stream's. That only
66/// bounds **re-projection** after a `-WipeDb`: the durable source of
67/// truth for ack_status is the `notification_acks` SQLite table, which
68/// persists independently — so a live fleet keeps full ack history;
69/// only a DB wipe truncates re-derivable acks to the EVENTS window,
70/// the same limitation every `events.*`-projected table already has.
71pub fn events_notifications_acked(pc_id: &str, user_sid: &str, notif_id: &str) -> String {
72 format!("events.notifications.acked.{pc_id}.{user_sid}.{notif_id}")
73}
74
75// `commands_exec` (subject `commands.exec.<job_id>`) was removed in
76// v0.22.1. The STREAM_EXEC stream now catches the existing
77// `commands.{all,group.X,pc.Y}` subjects directly, so the dedicated
78// per-exec subject isn't needed any more. See
79// `kanade-agent::command_replay` for how reconnecting agents catch
80// up on missed messages.
81
82pub fn results(request_id: &str) -> String {
83 format!("results.{request_id}")
84}
85
86pub fn heartbeat(pc_id: &str) -> String {
87 format!("heartbeat.{pc_id}")
88}
89
90/// `host_perf.<pc_id>` — Phase 1 of the perf telemetry pipeline. The
91/// agent publishes a whole-host CPU / Memory / Disk I/O / Network
92/// snapshot here on the cadence set by `host_perf_interval` in
93/// agent_config (default 60 s). Distinct subject from `heartbeat.<pc_id>`
94/// so the periodic heartbeat publisher stays untouched and pre-host_perf
95/// backends that don't subscribe simply ignore the new traffic.
96pub fn host_perf(pc_id: &str) -> String {
97 format!("host_perf.{pc_id}")
98}
99
100/// `process_perf.<pc_id>` — Phase 2: top-N per-process snapshot
101/// published only while `process_perf_enabled` is `true` AND the
102/// `process_perf_expires_at` deadline is in the future. Separate
103/// subject from `host_perf.<pc_id>` because process-perf is an
104/// opt-in investigation mode — having its own subject lets the
105/// projector skip the heavy table entirely for hosts that never
106/// turn it on.
107pub fn process_perf(pc_id: &str) -> String {
108 format!("process_perf.{pc_id}")
109}
110
111/// `obs.<pc_id>` — per-PC observability event stream (Issue #246).
112/// The agent publishes one [`crate::wire::ObsEvent`] per timeline
113/// event (sign-in / out, power on / off, sleep / resume, agent
114/// milestones, diagnostic bundle pointers). Distinct from
115/// `events.started.*` (in-flight script lifecycle) and
116/// `host_perf.<pc_id>` (numeric telemetry) — `obs.*` is the
117/// semantic-event stream the SPA Timeline page consumes.
118pub fn obs(pc_id: &str) -> String {
119 format!("obs.{pc_id}")
120}
121
122/// `obs.>` — filter the backend projector subscribes to so a new
123/// PC starts flowing into the timeline without any per-PC SUB
124/// registration. Pairs with [`obs`] for publish.
125pub const OBS_FILTER: &str = "obs.>";
126
127/// `kill.<exec_id>` — Spec §2.6 Layer 3 abort signal. The exec_id is
128/// the deployment / scheduler-fire UUID (formerly named `job_id`
129/// pre-v0.29; renamed for accuracy — every `Command.exec_id` is a
130/// per-deploy UUID, not a job-catalog id).
131pub fn kill(exec_id: &str) -> String {
132 format!("kill.{exec_id}")
133}
134
135pub fn inventory(pc_id: &str, category: &str) -> String {
136 format!("inventory.{pc_id}.{category}")
137}
138
139/// `events.started.<exec_id>.<pc_id>` — v0.30 / PR α' lifecycle
140/// event published by the agent just before spawning a script's
141/// child process. Lets the backend project an in-flight row into
142/// `execution_results` (with `finished_at = NULL`) so the SPA
143/// Activity table can show running rows alongside finished ones.
144/// Backend subscribes via [`EVENTS_STARTED_FILTER`].
145pub fn events_started(exec_id: &str, pc_id: &str) -> String {
146 format!("events.started.{exec_id}.{pc_id}")
147}
148
149/// Wildcard the backend events projector consumes on STREAM_EVENTS.
150/// Narrow (`events.started.>`) rather than the whole `events.>` so
151/// future event types can carry their own filters without rerouting
152/// the started subset.
153pub const EVENTS_STARTED_FILTER: &str = "events.started.>";
154
155/// Wildcard the backend notification-acks projector consumes on
156/// `STREAM_EVENTS`. Narrow (`events.notifications.acked.>`) rather
157/// than the whole `events.>` so the projector only wakes for ack
158/// events and not the high-volume `events.started.*` lifecycle
159/// traffic (which the events projector handles separately).
160pub const EVENTS_NOTIFICATIONS_ACKED_FILTER: &str = "events.notifications.acked.>";
161
162pub const INVENTORY_HW: &str = "hw";
163pub const INVENTORY_SW: &str = "sw";
164pub const INVENTORY_NET: &str = "net";
165
166/// `logs.fetch.<pc_id>` — request/reply: operator (or backend) sends
167/// a `LogsRequest`; the addressed agent replies with the tail of its
168/// local log file. On-demand only, no stream.
169pub fn logs_fetch(pc_id: &str) -> String {
170 format!("logs.fetch.{pc_id}")
171}
172
173/// `job.tail.<pc_id>` — request/reply for the live tail of a
174/// still-running job's stdout/stderr. The operator (or backend, on
175/// the SPA's behalf) sends a [`crate::wire::JobTailRequest`] carrying
176/// the `result_id`; the addressed agent replies with the current
177/// ring-buffer tail from its in-memory live registry. On-demand only,
178/// no stream — the SPA polls this every few seconds (same shape as
179/// `logs.fetch.<pc_id>`) while a job is in flight. Distinct subject
180/// from `logs.fetch.<pc_id>` (whole-agent log file) because this is
181/// scoped to a single job's captured output, not the agent's log.
182pub fn job_tail(pc_id: &str) -> String {
183 format!("job.tail.{pc_id}")
184}
185
186/// `agents.<pc_id>.ping` — v0.38 / #133 request/reply for the
187/// active "ping" round-trip. The agent answers with a fresh
188/// `Heartbeat` on demand instead of the backend waiting up to ~30 s
189/// for the next periodic heartbeat tick to land. Distinct subject
190/// from `heartbeat.<pc_id>` so the periodic publisher is unaffected
191/// and old agents that don't subscribe simply time the request out.
192pub fn ping(pc_id: &str) -> String {
193 format!("agents.{pc_id}.ping")
194}
195
196// v0.14: subject::inventory_request was retired alongside the
197// hardcoded inventory loop. On-demand collection now goes through
198// the normal exec path (`kanade exec configs/jobs/inventory-
199// hw.yaml`) — Command + ExecResult + the inventory-fact projector
200// give operators the same effect with no extra subject.
201
202#[cfg(test)]
203mod tests {
204 use super::*;
205
206 #[test]
207 fn commands_all_constant() {
208 assert_eq!(COMMANDS_ALL, "commands.all");
209 }
210
211 #[test]
212 fn commands_group_formats_name() {
213 assert_eq!(commands_group("canary"), "commands.group.canary");
214 assert_eq!(commands_group("wave1"), "commands.group.wave1");
215 }
216
217 #[test]
218 fn commands_pc_formats_id() {
219 assert_eq!(commands_pc("pc-01"), "commands.pc.pc-01");
220 assert_eq!(commands_pc("PC1234"), "commands.pc.PC1234");
221 }
222
223 #[test]
224 fn notifications_all_constant() {
225 assert_eq!(NOTIFICATIONS_ALL, "notifications.all");
226 }
227
228 #[test]
229 fn notifications_group_formats_name() {
230 assert_eq!(
231 notifications_group("tokyo-office"),
232 "notifications.group.tokyo-office"
233 );
234 }
235
236 #[test]
237 fn notifications_pc_formats_id() {
238 assert_eq!(notifications_pc("PC1234"), "notifications.pc.PC1234");
239 }
240
241 #[test]
242 fn notifications_amend_subject_constant() {
243 // Pin the value: backend publisher and every agent subscriber must
244 // agree on it, and it must stay OUTSIDE `notifications.>` so the
245 // NOTIFICATIONS stream never retains these ephemeral control messages.
246 assert_eq!(NOTIFICATIONS_AMEND_SUBJECT, "notif-amend");
247 assert!(!NOTIFICATIONS_AMEND_SUBJECT.starts_with("notifications."));
248 }
249
250 #[test]
251 fn events_notifications_acked_formats_all_segments() {
252 assert_eq!(
253 events_notifications_acked("PC1234", "S-1-5-21-1001", "notif-9f3a"),
254 "events.notifications.acked.PC1234.S-1-5-21-1001.notif-9f3a"
255 );
256 }
257
258 #[test]
259 fn events_notifications_acked_filter_is_narrow_wildcard() {
260 assert_eq!(
261 EVENTS_NOTIFICATIONS_ACKED_FILTER,
262 "events.notifications.acked.>"
263 );
264 // Must stay a strict subset of the EVENTS stream's `events.>`
265 // subjects so STREAM_EVENTS retains it without a config change.
266 assert!(EVENTS_NOTIFICATIONS_ACKED_FILTER.starts_with("events."));
267 }
268
269 #[test]
270 fn results_formats_request_id() {
271 assert_eq!(results("req-1"), "results.req-1");
272 }
273
274 #[test]
275 fn heartbeat_formats_pc_id() {
276 assert_eq!(heartbeat("pc-01"), "heartbeat.pc-01");
277 }
278
279 #[test]
280 fn host_perf_formats_pc_id() {
281 assert_eq!(host_perf("pc-01"), "host_perf.pc-01");
282 assert_eq!(host_perf("PC1234"), "host_perf.PC1234");
283 }
284
285 #[test]
286 fn process_perf_formats_pc_id() {
287 assert_eq!(process_perf("pc-01"), "process_perf.pc-01");
288 assert_eq!(process_perf("PC1234"), "process_perf.PC1234");
289 }
290
291 #[test]
292 fn obs_formats_pc_id() {
293 assert_eq!(obs("pc-01"), "obs.pc-01");
294 assert_eq!(obs("PC1234"), "obs.PC1234");
295 }
296
297 #[test]
298 fn obs_filter_constant() {
299 assert_eq!(OBS_FILTER, "obs.>");
300 }
301
302 #[test]
303 fn kill_formats_exec_id() {
304 assert_eq!(kill("exec-uuid-1"), "kill.exec-uuid-1");
305 }
306
307 #[test]
308 fn logs_fetch_formats_pc_id() {
309 assert_eq!(logs_fetch("pc-01"), "logs.fetch.pc-01");
310 }
311
312 #[test]
313 fn ping_formats_pc_id() {
314 assert_eq!(ping("pc-01"), "agents.pc-01.ping");
315 }
316
317 #[test]
318 fn job_tail_formats_pc_id() {
319 assert_eq!(job_tail("pc-01"), "job.tail.pc-01");
320 assert_eq!(job_tail("PC1234"), "job.tail.PC1234");
321 }
322
323 #[test]
324 fn events_started_formats_exec_id_and_pc_id() {
325 assert_eq!(
326 events_started("exec-uuid-1", "pc-01"),
327 "events.started.exec-uuid-1.pc-01",
328 );
329 }
330
331 #[test]
332 fn events_started_filter_is_narrow_wildcard() {
333 assert_eq!(EVENTS_STARTED_FILTER, "events.started.>");
334 }
335
336 #[test]
337 fn inventory_formats_pc_id_and_category() {
338 assert_eq!(inventory("pc-01", "hw"), "inventory.pc-01.hw");
339 assert_eq!(inventory("pc-01", INVENTORY_HW), "inventory.pc-01.hw");
340 assert_eq!(inventory("pc-01", INVENTORY_SW), "inventory.pc-01.sw");
341 assert_eq!(inventory("pc-01", INVENTORY_NET), "inventory.pc-01.net");
342 }
343}