Skip to content
This repository was archived by the owner on Jul 24, 2026. It is now read-only.

fix(up): a worker crash dings its SUPERVISOR again, not just the CoS (crash-ding regression) - #102

Merged
myobie merged 1 commit into
mainfrom
fix-crash-ding-supervisor
Jul 21, 2026
Merged

fix(up): a worker crash dings its SUPERVISOR again, not just the CoS (crash-ding regression)#102
myobie merged 1 commit into
mainfrom
fix-crash-ding-supervisor

Conversation

@myobie

@myobie myobie commented Jul 21, 2026

Copy link
Copy Markdown
Collaborator

Finding (from the evals crash-ding cell)

On a worker crash, convoy up's crash-ding reaches the CoS/orchestrator but not the crashed worker's supervisor (cd-sup's inbox stays empty). Answer: this is a regression, not a stale expectation — the two-recipient design (CoS and the supervisor) is correct (it's the #48 design; the agent-file supervisor field and crashDingTargets' convoy.spawner branch exist for exactly this).

Root cause

crashDingTargets correctly pages the CoS (convoy.tier=cos) plus crashed.tags["convoy.spawner"] (the supervisor). But the declarative arc broke the wiring that sets convoy.spawner:

  1. agentFileToSpec dropped supervisor — the declared supervisor never reached the launch path (the field was documented as "reconcile does not yet build the supervision tree from it").
  2. writeAgentFiles stamped convoy.spawner from the launching process's ST_AGENT — which, in the declarative flow, is the convoy up host, not the parent. So a declared worker's convoy.spawner became the host (often == the CoS → deduped away), and its real supervisor was never dinged.

Fix

  • carry supervisor on AgentSpec;
  • map af.supervisor → spec.supervisor in agentFileToSpec;
  • stamp convoy.spawner = spec.supervisor ?? process.env.ST_AGENT in writeAgentFiles — the declared supervisor is authoritative; ST_AGENT stays the fallback for the imperative convoy run path.

Tests

+2 regression tests (533 total pass, typecheck clean): agentFileToSpec carries supervisor; writeAgentFiles prefers the declared supervisor over the host's ST_AGENT (and falls back to ST_AGENT when none is declared).

For the eval cell

Keep the two-recipient expectation. Once this lands and the worker is launched fresh (the cell spins a new network each run) with --supervisor <cd-sup> declared, its pty.toml gets convoy.spawner = cd-sup, so a crash pages both cd-cos and cd-sup. (Already-running workers keep their old tag until re-rendered.)

🤖 Generated with Claude Code

https://claude.ai/code/session_01MCzqQKSpPiNX2ketyubByS

…(crash-ding regression)

On a worker crash, `convoy up`'s crash-ding is meant to page BOTH the CoS (the
always-on backstop, via convoy.tier=cos) AND the worker's actual supervisor (via
its convoy.spawner tag) — the two-recipient design from #48.

The declarative arc broke the supervisor half. `agentFileToSpec` DROPPED the
agent file's `supervisor` field, so it never reached the launch path; and
`writeAgentFiles` stamped convoy.spawner from the LAUNCHING process's ST_AGENT —
which, in the declarative flow, is the `convoy up` HOST, not the parent. So a
declared worker's convoy.spawner became the host (often == the CoS, then deduped),
and its real supervisor was never dinged.

Fix: carry `supervisor` on AgentSpec, map af.supervisor → spec.supervisor in
agentFileToSpec, and stamp convoy.spawner = spec.supervisor ?? ST_AGENT in
writeAgentFiles. The declared supervisor is now authoritative; ST_AGENT stays the
fallback for the imperative `convoy run` path (no declared supervisor).

Surfaced by the evals crash-ding cell (cd-cos got the notice; cd-sup's inbox
stayed empty). +2 regression tests: agentFileToSpec carries supervisor, and
writeAgentFiles prefers the declared supervisor over the host's ST_AGENT.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MCzqQKSpPiNX2ketyubByS
@myobie
myobie merged commit a845a27 into main Jul 21, 2026
2 checks passed
@myobie
myobie deleted the fix-crash-ding-supervisor branch July 21, 2026 12:57
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant