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

MGS8004: output ref was produced on a different machine

magus x <ref> reproduces the invocation a reference recorded. Before running, it computes this workspace's cache key for that invocation and compares it with the key stored in the ref. When the two differ, the recorded artifact cannot replay and the target runs instead.

That much is not an error. This diagnostic exists because "it runs instead of replaying" is the half you already know; the useful half is why.

MGS8004: ref out13f5a539577d was produced on a different machine, so this runs the target rather than replaying it
  platform    recorded linux/amd64             here darwin/arm64
  vcs         recorded jj                      here git
  sources hash identically across platforms, so the artifact would be refused on import

Only fields that differ appear, so every row is part of the diagnosis.

What each row means

platform: GOOS/GOARCH. The strongest cause: readManifest and importArtifact refuse a cross-platform artifact regardless of any setting, so replay is impossible rather than unlikely. Source content hashes are identical across platforms (the same commit digests the same everywhere), which is precisely why the cache key cannot see this and the manifest guard has to.

key version: the KeyVersion that produced each key. Keys computed by different versions are not comparable at all, so this can never resolve into a replay no matter how identical the sources are. It changes only when magus changes which fields are hashed.

magus: the binary that recorded the ref. Informational: a different version often still reproduces, and is listed so a surprising result has a candidate cause.

vcs: the provider the revision came from (git, hg, jj). A git SHA and a Mercurial node id are both 40 hex characters, so magus compares revisions only when the providers agree; when they differ, the revision row is omitted rather than rendering a confident comparison of two unrelated identifiers.

revision: the commit each side's inputs were read at, shown only when the providers match.

What magus does about it

Nothing automatic, deliberately. It reports and then runs the target.

It never checks out the recorded revision: moving your working tree would discard uncommitted work to satisfy a diagnostic. The commit is named so you can decide.

A ref recorded from a dirty working tree carries a separate warning, because a revision alone cannot reproduce a tree that had uncommitted edits; Revision is necessary but not sufficient there.

Fixing it

  • platform: reproduce on the same OS and architecture, or accept the rebuild. There is no way to replay another platform's artifact, by design.
  • key version: use a magus whose KeyVersion matches the one that recorded the ref, or accept the rebuild. The key version changes rarely and always invalidates.
  • revision: check out the named commit yourself, then re-run magus x <ref>.
  • vcs: the workspace resolved a different provider than the recording machine. Autodetection probes markers most-specific-first, so a colocated jj repository (which contains both .jj and .git, because git is jj's storage backend) resolves as jj on both machines. A difference here means the two are under different version control; set vcs.name to pin it.

See also

Output-reference diagnosticsLanding page for MGS8xxx diagnostics that flag problems resolving a target-output reference id with magus query, such as a ref that aged out of the cache, an ambiguous prefix, or a malformed ref passed to a ref-only flag. Console APILoopback JSON API the console reads your live workspace through (the graph, insight, diff, run-output, plan and ledger routes). Loopback only, bearer token, GET except where named. Mutation sits in a few bounded services beside it, none of which touches your working tree. magus commandStandalone build orchestrator and content-addressed cache for polyglot monorepos, with workspace-aware subcommands for build, test, lint, and inspect. Remote spellsImport a spell published as an OCI artifact by its registry path. magus.yaml declares the tag, magus.lock pins the manifest digest, only the update charm resolves a tag, and a pinned spell loads offline once cached.
output-refreproducecache-keyplatformdiagnostics
Last updated (353014be)
Earlier changes on this page (3)

Full history ↗ · Blame source ↗

Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. Workspace in full.

Target

A named operation (build, test, ...) you invoke with magus run <target>; it may compose a spell's tool-native operations and depend on other targets. Target in full.

Manifest

The file that declares what a package is: its name, dependencies, entry points and tool config (go.mod, package.json, pyproject.toml, Cargo.toml). How the workspace builds, tests and lints the package belongs in the magusfile, not in the manifest's scripts. Manifest in full.

Cache

The content-addressed store magus consults before running a target, so unchanged work is skipped. Cache in full.

CI

An ordinary target you compose yourself with ctx.needs; magus does not hardcode its stages. It is the anchor magus affected ci keys off, and ci strips the rw charm. CI in full.

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. Invocation in full.

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. Run in full.

Conventions

Placeholders

Angle brackets mark a value you replace with your own; never type the brackets:

magus run <target>
magus completion <shell>    # e.g. bash, zsh, fish

<target>, <path>, <shell>, <name> and the like are stand-ins, not literal text.