@track — opt-in function spans
@track records the same span events as auto-trace (function.enter / function.exit, with args, result, duration, and escaping exceptions) — but explicitly, with per-function control:
When to use it
- Code outside the project root — auto-trace only covers files under the directory containing
.slomo/.@trackforce-traces anything: shared internal libraries, vendored code, a hot third-party function you care about. - Capture control — keep the span but drop sensitive or oversized values for one specific function.
- Stable naming — pin a span name that survives refactors.
Functions carrying
@track are never double-recorded: auto-trace registers tracked code objects and defers to the decorator.Sync, async, and generators
@track handles all four callable shapes transparently:
await, so child calls nest correctly in the trace tree.
Zero overhead when disabled
When the recorder is not active, the wrapper short-circuits straight to your function — no span ids, no timestamps, effectively free. You can leave@track in production code unconditionally.
snapshot() — explicit variable capture
variable.snapshot event with a label and any keyword arguments. Use it at decision points you’ll want to see during replay: before a retry, after a cache miss, at the top of a suspicious branch.
The label is optional and positional-only:
slomo vars.
event() — custom domain events
custom event with a name, an optional severity (debug, info, warning, error, critical — default info; unknown strings fall back to info), and any keyword payload.
Custom events show up in slomo timeline, are searchable (slomo search cache.warmed), and severity warning+ appears under slomo timeline --errors. Use them for the domain milestones a debugger can’t infer: job started, batch committed, feature flag evaluated.
Both are safe no-ops when recording is off
Like@track, snapshot() and event() return immediately when the recorder is inactive. Instrument freely; the calls cost nothing unless slomo is enabled.