phughk/ottyl
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Document EngineHandle's already-realized primary/profile routing (ticket 106)

Browse Source 
Ticket 106 asked for a real way for API handlers to address the
primary vs. profile actor. That routing was already built out of
necessity while landing tickets 104/105 (metric queries had to reach
the profile actor's snapshot for those tickets' own tests to pass) --
EngineHandle ended up as one combined handle (option (b) from the
ticket's own scope note) that internally proxies metric/alert writes
to the profile actor and routes MetricDeclarations/BucketValues/Promql
reads to its snapshot, with no changes needed to any API handler,
reload_engine_declarations/activate_profile, or Profile::load_into_engine
-- they already just send EngineMessages the same way they did before
the split. mcp_server.rs talks to the HTTP API rather than EngineHandle
directly, so it needed no changes either. This commit documents that
resolution in handle.rs so a future reader doesn't go looking for
routing logic that isn't there.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TeyhRfMYjMditek6geDRoQ
This commit is contained in:
Hugh Kaznowski
2026-09-07 13:56:59 +01:00
co-authored by Claude Sonnet 5
parent 3751508de8
commit 3ee6dddb0e
2 changed files with 11 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/engine/handle.rs
+11
View File
@@ -1,5 +1,16 @@
//! The left-right write/read plumbing around `EngineSnapshot`, the actor loop that owns it,
//! and the `EngineHandle` other tasks use to talk to that actor.
//!
//! Ticket 106 (giving API handlers a route to both the primary and profile actors) resolved to
//! option (b) from its own scope note: one combined `EngineHandle`, not two separate handle
//! types. Callers never pick a target explicitly -- `EngineHandle::tx` accepts every
//! `EngineMessage` variant, and `run()` below internally proxies the metric/alert-related ones
//! to the profile actor (`super::profile::ProfileMessage`) rather than mutating the primary's
//! own snapshot; `EngineHandle::profile_reader` similarly gives read access to the profile
//! actor's snapshot for the query variants it owns (routed in `api::EngineHandle::ask`). This
//! means `reload_engine_declarations`/`activate_profile`/`Profile::load_into_engine` needed no
//! changes at all to correctly split their remove-then-redeclare sequence across both actors --
//! they already just send `EngineMessage`s the same way they did before the split.
use crate::config::SettingsHandle;
use crate::consts::{INGEST_LAG_WATERMARK_MAX_ENTRIES, INGEST_LAG_WATERMARK_WINDOW_MS};