fix: correct invalid Node24 execution handler (#31)#32
Merged
Conversation
…sion The execution blocks used "Node24_1", which is not a valid Azure Pipelines handler name and was therefore silently ignored by every agent. The correct key is "Node24". This meant tasks never ran on the Node 24 runtime and, on agents that recognized none of the listed handlers, failed with the misleading "A supported task execution handler was not found ... not compatible with your current operating system" error (issue #31). - Rename Node24_1 -> Node24 in all 5 task.json files. - Keep Node20_1 (modern agents) and plain Node20 (on-prem ADO Server v3.224-v3.230, added deliberately in #29). - Add minimumAgentVersion 3.224.1 (release where the Node 20 handler first shipped, the floor of the lowest handler) so older agents get a clear minimum-version error instead of the cryptic handler message. This cannot block any agent that could otherwise run the task. - Normalize execution-block indentation and trailing newline. Refs #31, #29 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
All three execution handlers point to the same dist/index.js, so the single shared bundle can be selected to run on the Node 20 runtime (Node20_1 / Node20 handlers). Targeting node24 risked emitting syntax newer than Node 20 can run. Lower the esbuild target to node20 so the bundle is valid on the lowest runtime it can land on. esbuild target is a compatibility floor, not an optimization, so this has no effect on Node 24 execution. Refs #31 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Assert the valid Node24 handler (not Node24_1), require Node20_1 and Node20, add a guard that the invalid Node24_1 key is absent, and assert the new minimumAgentVersion value. Refs #31 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- README: add a Troubleshooting section explaining the misleading "supported task execution handler was not found" error, the v3.224.1 agent baseline, and the upgrade / NodeTaskRunnerInstaller@0 workarounds (incl. on-prem). - Replace incorrect Node24_1 references with Node24 and note the new minimumAgentVersion in ARCHITECTURE.md, copilot-instructions.md, and CONTRIBUTING.md. Refs #31 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
1 participant
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.
Summary
Fixes the misleading "A supported task execution handler was not found ... not compatible with your current operating system 'Windows(X64)'" error reported in #31.
Despite the wording, this Azure DevOps error is not about the OS. The agent emits it when it recognizes none of the Node execution handlers listed in
task.json.Root cause
All 5
task.jsonfiles listedNode24_1as the primary handler. Verified against the livemicrosoft/azure-pipelines-agentsource:Node24_1has never been a valid handler name — the correct key isNode24. The agent silently ignored it, so tasks only ever resolved toNode20_1(modern agents) or plainNode20(on-prem ADO Server v3.224–v3.230, added in #29). On any agent that recognized none of the three, the task failed with the cryptic error.Changes
Node24_1→Node24; keepNode20_1and plainNode20(the on-prem handler from Allow older ADO Node20 execution handler/runtime #29 stays). Normalize indentation/trailing newline.minimumAgentVersion: "3.224.1"(×5): the agent release where the Node 20 handler first shipped (PR Support Node 20 handler microsoft/azure-pipelines-agent#4346) — i.e. the floor of our lowest handler. Old agents now get a clear minimum-version error instead of the cryptic handler message. This cannot block any agent that could otherwise run the task.node24→node20. The single shared bundle can run on the Node 20 runtime, so it must target the lowest runtime.targetis a compatibility floor, not an optimization — no effect on Node 24 execution.scaffold.test.tsto assertNode24/Node20_1/Node20, guard againstNode24_1reappearing, and checkminimumAgentVersion.NodeTaskRunnerInstaller@0, incl. on-prem note); fixedNode24_1references in ARCHITECTURE.md, copilot-instructions.md, CONTRIBUTING.md.For agents older than v3.224.1
The code fix can't help agents that predate the Node 20 handler. Those users should upgrade the agent or add
NodeTaskRunnerInstaller@0before the ALCops task — both documented in the new README troubleshooting section.Verification
npm test— 46 passednpm run build— cleannpm run bundle— clean (node20 target)npm run lint— cleanNon-breaking (no YAML input contract change → no task Major bump).
Closes #31
Refs #29
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com