What happened
Driving a multi-platform CI run through the odu MCP (x86_64-linux + aarch64-darwin e2e), the linux lane failed on a flaky test while the darwin lane was still running. I wanted to retry just the linux lane, concurrently, without disturbing darwin.
From the tool surface I had, the only thing that looked like "retry" was mcp__odu__run with supersede — whose description says "One run per checkout" and "Strict by default… one run per checkout." So I reasoned (and wrote, to the user): "a linux retry means superseding, which cancels the in-flight darwin lane." That's wrong, and a human had to correct me.
The right tool — mcp__odu__node_rerun — does re-run a single node (ci::e2e@x86_64-linux) on a live run, concurrently with the still-running sibling lane, no supersede and no cancellation. I verified it: node_rerun returned {ok:true}, the linux e2e re-ran on the (now-free) leased box, the darwin lane kept going, and the run settled with linux green + darwin's own result intact.
The gap
node_rerun ships with no description. In the MCP schema it's just { name: "node_rerun", parameters: { id } } — no text at all. An agent sees a bare id param and no hint of what it does, when it applies, or that it works on a live run.run's description actively points the other way. "One run per checkout" + a prominent supersede flag, with nothing alongside it about retrying an individual node, leads an agent to conclude that retrying one lane requires replacing the whole run (and thus killing other in-flight lanes).- Net effect: the safe, cheap, correct operation (concurrent single-node retry) is invisible, and the expensive, destructive one (supersede) is the only one that's documented — exactly backwards for the common "one lane flaked, retry it" case.
Ask
- Give
node_rerun a real description in the MCP server, e.g.: "Re-run a single node (e.g. ci::e2e@x86_64-linux) by id. Works on a live run and runs concurrently with other in-flight lanes — no supersede, nothing else is cancelled. Use this to retry a failed/flaky lane mid-run. (After a run has fully settled the coordinator has exited; start a fresh single-platform run instead.)"
- Cross-reference it from
run/supersede: note that supersede restarts the whole run and cancels in-flight lanes, so it's not the way to retry one flaky lane — node_rerun is.
- Same clarification in the odu-mcp skill/docs that agents read.
Small doc/description change, but it's the difference between an agent doing the right thing automatically and one throwing away a 6-minute darwin lane (or telling the user it has to).
— filed while running CI for juspay/kolu#1412
What happened
Driving a multi-platform CI run through the odu MCP (
x86_64-linux+aarch64-darwine2e), the linux lane failed on a flaky test while the darwin lane was still running. I wanted to retry just the linux lane, concurrently, without disturbing darwin.From the tool surface I had, the only thing that looked like "retry" was
mcp__odu__runwithsupersede— whose description says "One run per checkout" and "Strict by default… one run per checkout." So I reasoned (and wrote, to the user): "a linux retry means superseding, which cancels the in-flight darwin lane." That's wrong, and a human had to correct me.The right tool —
mcp__odu__node_rerun— does re-run a single node (ci::e2e@x86_64-linux) on a live run, concurrently with the still-running sibling lane, no supersede and no cancellation. I verified it:node_rerunreturned{ok:true}, the linux e2e re-ran on the (now-free) leased box, the darwin lane kept going, and the run settled with linux green + darwin's own result intact.The gap
node_rerunships with nodescription. In the MCP schema it's just{ name: "node_rerun", parameters: { id } }— no text at all. An agent sees a bareidparam and no hint of what it does, when it applies, or that it works on a live run.run's description actively points the other way. "One run per checkout" + a prominentsupersedeflag, with nothing alongside it about retrying an individual node, leads an agent to conclude that retrying one lane requires replacing the whole run (and thus killing other in-flight lanes).Ask
node_reruna real description in the MCP server, e.g.: "Re-run a single node (e.g.ci::e2e@x86_64-linux) by id. Works on a live run and runs concurrently with other in-flight lanes — nosupersede, nothing else is cancelled. Use this to retry a failed/flaky lane mid-run. (After a run has fully settled the coordinator has exited; start a fresh single-platformruninstead.)"run/supersede: note thatsupersederestarts the whole run and cancels in-flight lanes, so it's not the way to retry one flaky lane —node_rerunis.Small doc/description change, but it's the difference between an agent doing the right thing automatically and one throwing away a 6-minute darwin lane (or telling the user it has to).
— filed while running CI for juspay/kolu#1412