launch-task: derive worker report address from the launcher's identity#230
Open
gnguralnick wants to merge 3 commits into
Open
launch-task: derive worker report address from the launcher's identity#230gnguralnick wants to merge 3 commits into
gnguralnick wants to merge 3 commits into
Conversation
A task file authored with the Write tool (rather than the documented heredoc) can carry a literal `lead_agent: $MNGR_AGENT_NAME` because no shell expansion runs. The worker then has no valid address to rsync its report to, so it silently never reports back and the lead's poll waits until timeout. create_worker.launch now resolves lead_agent before provisioning: if the value is unresolved (missing, empty, or contains an unexpanded `$...`), it is rewritten to the launching agent's MNGR_AGENT_NAME (the agent that will poll for the report). If the value is unresolved and MNGR_AGENT_NAME is unset, launch fails fast (exit 2) instead of creating an unaddressable worker. Already-resolved author-set names are left untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Don't trust the task file's lead_agent at all when the launcher knows its own identity. The agent running `launch` IS the lead that polls for the report, so its MNGR_AGENT_NAME is authoritative: stamp it into the task file, overwriting whatever the file holds (a literal $MNGR_AGENT_NAME, a stale name, or nothing). Authors no longer need to set the field. The file value is used only as a fallback when MNGR_AGENT_NAME is unset (launch run outside an mngr agent, e.g. manually or in tests); an unresolved value in that case is still fatal (exit 2). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
gnguralnick
changed the title
The worker launcher now stamps lead_agent from its own MNGR_AGENT_NAME, so task-file authors no longer set it. Remove the lead_agent line from every task-file frontmatter template and drop it from the prose that listed the reporting fields, across launch-task, crystallize-artifact, update-artifact, heal-artifact, update-system-interface, and use-ai-integration. finish_report_path stays author-supplied. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
joshalbrecht
reviewed
Jul 6, 2026
Comment on lines
+271
to
+272
| except yaml.YAMLError: | ||
| return None # malformed YAML surfaces later via _read_source_artifacts_dir |
Contributor
There was a problem hiding this comment.
sure, but why not let it blow up right away?
Contributor
|
lgtm except for my one minor comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A worker reports back by
mngr rsync-ing its report to thelead_agentnamed in its task file's frontmatter. That value was author-supplied, so it could be wrong: a task file authored with the Write tool (instead of acat <<EOFheredoc) carries a literal, unexpandedlead_agent: $MNGR_AGENT_NAME; a value can also be stale or omitted. In any of those cases the worker has no valid address — it finishes successfully but the report never lands at the lead'sfinish_report_path, and the lead'sawaitpoll waits until timeout. The failure is silent.This was hit in practice: an
update-pr-reviewharden worker completed all gates but could not deliver its report.Fix
Stop trusting the task file for this at all. The agent running
create_worker.launchis the lead that polls for the report, so its ownMNGR_AGENT_NAMEis the authoritativelead_agent.launchnow stamps it into the task file before provisioning, overwriting whatever the file holds (and inserting it if absent). Authors no longer need to set the field.Fallback for non-agent contexts: when
MNGR_AGENT_NAMEis unset (e.g.launchrun manually or in a test), the file's existing value is used; an unresolved value (missing, blank, or an unexpanded$…) in that case is fatal (exit 2) rather than launching an unaddressable worker.This assumes the launcher is always the report recipient, which holds throughout this codebase (the launcher is the poller). A future cross-agent dispatch would add an explicit recipient argument rather than reviving the trust-the-file behavior.
Tests
create_worker_test.py:$MNGR_AGENT_NAMEis replaced from the envmngr create)_set_frontmatter_fieldreplace / insert / no-frontmatter behavioruv run pytest .agents/skills/launch-task/scripts/create_worker_test.py→ 53 passed.🤖 Generated with Claude Code