magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit

Services diagnostics

Codes in the MGS5xxx range flag problems with long-running service ops: services that will run as separate processes when they look like they should be one shared instance, and (later) op invocations that contradict their declared kind. Magus raises them at run time (as a typed DiagnosticError) and, where applicable, as a magus doctor health check so the gap is visible before the work runs.

Codes

  • MGS5001: near-duplicate services that will run as separate processes.
  • MGS5002: a service op detaches, breaking foreground supervision.
  • MGS5003: a command op runs a watcher and never exits.
servicesdiagnosticserror codesMGS5xxxservice opdoctorsharing
Last updated (39e02449)
Earlier changes on this page (1)

Full history ↗ · Blame source ↗

Glossary

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). See operations.

Service

A long-running or shared process magus manages across runs, distinct from a one-shot target. See services.

Health

The at-a-glance server state derived from the pool: healthy when the pool is reporting, degraded when it reports an error, down when there is no pool. The dashboard color-codes each state. See server.

Invocation

One magus process's recorded facts - the targets it finished, their outcomes, the lease it acted as, and the session it ran in when a host delivered one - kept in a repo-scoped store every worktree shares. magus session lists them; the store prunes itself by last-fact age.

Run

One target executing under one magus invocation, such as magus run test web or magus affected ci. A run keeps its captured output behind an output reference. Every magus run is a run whether or not any job asked for it; see Job for how the two relate.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.