ottyl/tickets/101-extract-metric-computation-into-separate-stage.md

101 — Metric computation is inlined into the single ingest actor's write closure, not a separately-callable stage

Summary

Per-line ingest currently does ingest-lag bookkeeping, log-stream header detection, raw-text storage, auto-param detection, and every declared metric's regex evaluation, all synchronously inside one write.mutate(...) closure in the actor's run() loop, followed by alert evaluation against the result in the same message handler. This is migration step 2 of 0001-actor-split's resolved plan: pull metric computation out into a stage that can be called independently of the ingest closure — still within the single actor for now — so that step 3 (splitting into reader/primary/profile actors) is a wiring change rather than also being the first time metric computation is separated from raw ingest. Depends on 100-arc-ify-stored-log-and-metric-strings landing first (Arc'd text is what makes passing a line into a separate stage cheap).

Where

• src/engine/handle.rs:132-224 (run()'s EngineMessage::Ingest arm) — the closure passed to write.mutate at :180-198 does header detection, storage, auto_declare_params, and snap.apply_all_metrics(sequence, timestamp, &text_for_op) (:196) all in one synchronous block; alert evaluation follows immediately after at :199-219, reading the snapshot metric computation just produced.
• src/engine/snapshot/mod.rs:616 (apply_all_metrics) — the entry point that iterates every declared metric and calls apply_metric_to_log (:499-586) per match; currently only reachable as a method on EngineSnapshot invoked from inside the ingest closure above.
• src/engine/alerts.rs:211 (evaluate_alerts) — currently called directly from the ingest arm (handle.rs:199-219) against the snapshot mutated by the same message; this is the alert-evaluation call site that migration step 3 will later move to a profile actor (per 0001-actor-split's "Resolved decisions" — not in scope for this ticket).

Scope

• Extract param-extraction (header detection, auto_declare_params, raw storage) and metric-computation (apply_all_metrics) into separate, independently-callable functions/methods with a clear boundary between them — e.g. a function that takes a line and returns/records derived params only, and a second that takes the declared-metrics set plus a param-resolved line and returns bucket updates — rather than one closure that does both inline.
• Keep both stages running inside the same actor and the same write.mutate transaction for this ticket — the goal is a clean internal seam, not concurrency yet. Step 3 (a separate ticket, not this one) is what actually moves metric computation to a different task.
• Do not change alert evaluation's behavior or its current call site relative to metric computation (still immediately after, same actor) — only prepare the metric-computation code so it's callable as its own unit; moving alerts to a profile actor is explicitly step 3's concern per 0001-actor-split's resolved decisions.
• Out of scope: the reader/primary/profile actor split itself, any new tokio::sync::watch signaling, and any change to EngineHandle's public API — this ticket is an internal refactor within the existing single-actor structure.