marin-community/marin#7470 - 2-way sync via ghpr (https://github.com/runsascoded/ghpr)

marin#7470.md

marin-community/marin#7470 [rigging] username_segment: prefer launch identity over worker OS user

username_segment() now resolves the launch identity carried in MARIN_PROVENANCE (built_by, stamped into the job env by the submitting client since #7000) before falling back to the OS login. On an Iris worker the OS login is root, so users/<seg>/ checkpoints from remote runs all landed under users/root/ (~275 GB across 3 buckets in the week to 2026-07-20) even though .artifact.json built_by correctly named the submitting human. The env payload is parsed directly (no git subprocess); a malformed payload warns and falls back to the OS login, a valid payload without built_by falls back silently (the submitting host not resolving a user is absence, not an error), and the unresolvable case still raises.

When the resolved segment is a known machine login (root, runner, ubuntu, exedev), a warning is logged: a per-user namespace under a machine identity always means launch identity was not threaded somewhere upstream.

z-3625379658-00-Copilot.md

PR description says an absent built_by should warn and fall back to the OS login, but username_segment() currently falls back silently when MARIN_PROVENANCE parses successfully and built_by is None/empty. Either add an explicit warning for this case (distinct from the malformed-env warning) or update the PR description/tests to match the intended behavior.

z-3625379658-01-ryan-williams.md

🤖 The description was wrong, not the code — updated it. A valid payload with built_by=None falls back silently by design: the submitting host failing to resolve a user is absence, not an error, and when that fallback lands on a machine identity the machine-login warning already fires. The malformed-payload warning stays distinct.

z-3625518942-00-chatgpt-codex-connector[bot].md

Validate built_by before using it

When MARIN_PROVENANCE is malformed but still has the required top-level fields, for example {"tree_hash":"x","base_commit":"y","dirty":false,"built_by":123}, _provenance_from_env() returns a Provenance with a non-string built_by. username_segment() then selects that value and crashes at raw.strip() instead of warning and falling back to the OS login, so a bad env payload can still break per-user namespacing despite the intended malformed-payload fallback.

Useful? React with 👍 / 👎.

z-3625518942-01-ryan-williams.md

🤖 Real — a payload like {"tree_hash": ..., "built_by": 123} parsed and then username_segment() crashed at raw.strip(). Fixed in 25d23c99aa by validating in Provenance.from_json: a non-string built_by now raises TypeError, which _provenance_from_env already treats as malformed (warn + fall back to the OS login) for both capture() and username_segment(). Regression test added.

z5038749736-claude[bot].md

Claude encountered an error after 0s —— View job

---

I'll analyze this and get back to you.