forgekey: a command starts in a directory that exists (issue 734) #93

Merged

mesh-tools merged 2 commits from fix/daemon-dir-kept into main 2026-10-26 14:15:57 +00:00

Conversation 1 Commits 2 Files Changed 2

+43 -2

2 Commits

Author	SHA1	Message	Date
jschoubben	fd7d93333e	Keep a failed toolchain probe a loud refusal; only the command directory is fixed (issue 734, review round 1) ... Declining an ask whose probe failed would turn a truly broken toolchain into a wait of up to the decline bound that then fails with an empty "needs a node with" reason. With the node-engine no longer deleting a running build and commands started in a directory that exists, the getwd cause is gone, so the guard's refusal stays as it was. The decline refactor goes with it.	2026-10-26 15:11:04 +01:00
jschoubben	36061b5c56	Start commands in a directory that exists, and decline an ask whose toolchain could not be read (issue 734) ... A build module runs in the directory its build was unpacked in. When the node-engine replaced that build, every command the module started inherited a deleted working directory, and the toolchain probe's failure became a final refusal of the check that asked it (three checks on ace on 2026-10-26). forgekey: ExecRunnerClean starts its command in the HOME it is given, or the temporary directory; the other runners keep the process's directory while it exists and use the temporary directory once it is gone. buildstep: a guard whose probe failed answers a Refusal with Again set; the puller declines such an ask (delivery.StepDeclined) so its asker puts it again for another node or a later pull, instead of ending it refused. A version mismatch stays a refusal.	2026-10-26 15:01:57 +01:00