Missing debug adapter for VS Code extension on Windows

[erwinkramer]

Description

There doesn't seem to be any included debug adapter when trying the VS Code extension on a Windows machine. I would have expected one. I'd rather not depend on an Cargo installation, unless absolutely necessary. I would also be happy if it was included as a release asset, just like the CLI is included as exe.

Command

.

Output

Minimal Arazzo spec

Environment

Windows 11

[strefethen]

Thanks for the report, @erwinkramer — root-caused.

What happened: every Marketplace version so far (0.0.1–0.0.4) was published as a single universal package, and the bundled bin/arazzo-debug-adapter inside it is a macOS (Apple Silicon) binary. On Windows the extension looks for bin/arazzo-debug-adapter.exe, finds nothing, and shows the error in your screenshot. Linux and Intel macOS were affected too, with an uglier spawn failure, since the suffix-less file exists there but can't execute.

Fix: the extension now ships through a platform-matrix pipeline that builds the Rust debug adapter natively per platform and publishes platform-specific VSIXs — win32-x64 (plus experimental win32-arm64) each bundle arazzo-debug-adapter.exe, so no Cargo or Rust toolchain is needed on your machine. The same pipeline attaches every VSIX (with SHA256 checksums) to a GitHub release, so they're available as release assets as you suggested: https://github.com/strefethen/arazzo-cli/releases/tag/vscode-v0.0.5

0.0.5 is live on the Marketplace now — updating the extension in VS Code will pull the Windows build automatically. If the adapter still doesn't start after updating to 0.0.5, please reopen.

[strefethen]

The BS MSFT makes you go through to push a bundle to the marketplace is just next-level. Full Azure account with CC and an organization and so many hoops. That blows my mind. Had it not been for Claude, I've have just torn down the marketplace entry.

This is some of the worst DX I've seen in 30 years.

[erwinkramer]

@strefethen there is now an exe in the vscode folder, so that looks good:

However, when trying to debug, it gets to the first row, but then it just stops when I hit continue:

I also don't seem to see any logging under Output in vscode, there doesn't seem to be any Arazzo output channel at all, so it's hard for me to see what's going wrong now.

[strefethen]

Thanks for testing and following up, @erwinkramer — good to have the Windows binary confirmed, and both new symptoms you hit were real bugs on my side. 0.0.6 is published with fixes for both. But I want to be straight with you up front: for your particular spec, 0.0.6 will most likely turn a silent failure into a visible error rather than a working run. Details and a workaround below.

1. "It just stops when I hit continue"

A genuine defect in the debug adapter, not your spec. When a workflow failed, the adapter discarded the engine's error and sent VS Code a bare terminated event, so the session simply closed with nothing reported anywhere. Fixed in 0.0.6 — failures are now sent as an error message plus a non-zero exit code, so the cause shows up in the Debug Console.

2. "There doesn't seem to be any Arazzo output channel at all"

Correct, and my earlier note about an Output panel was wrong — the extension never created one. 0.0.6 adds an "Arazzo Debug" output channel that logs session start/end, which adapter binary was launched, workflow exit codes, and adapter errors. It reveals itself automatically if the adapter fails to start.

3. What you'll see next, and the remaining blocker

I reproduced your setup locally. With 0.0.6 the session should now report:

workflow failed: operationId "GetAllBanks" not found in loaded OpenAPI specs

Your sourceDescriptions entry is written correctly per the Arazzo spec — the url points at the OpenAPI document:

sourceDescriptions:
  - name: bankApiV1
    url: https://app.bravestone-.../v1/openapi/spec.json
    type: openapi

The gap is on our end: arazzo-cli doesn't fetch remote source documents yet. It historically treated sourceDescriptions[].url as the API base URL rather than a document to load, and existing workflows depend on that meaning, so I couldn't silently reinterpret absolute http(s) URLs as "fetch this" without breaking them. What 0.0.6 does add is automatic loading for relative urls, resolved against the Arazzo file's own directory.

Workaround that works today

You already have the spec committed, so pointing at it relatively is enough — verified against your actual files:

sourceDescriptions:
  - name: bankApiV1
    url: ../Specs.Generated/openapi_v1_spec.json
    type: openapi

That resolves GetAllBanks and produces GET https://localhost:5201/v1/banks.

One caveat worth knowing: the request base URL then comes from that document's servers block, and the copy in your repo declares https://localhost:5201/v1 — so it targets your local instance. To hit the deployed container app instead, give the local copy a matching servers entry.

Also worth noting: OpenAPI 3.2 is not a problem for run/debug. The runtime indexes operationIds without the typed 3.0 parser that trips up generate in #3 — I confirmed GetAllBanks indexes fine from your 3.2 spec.

What's next

Remote sourceDescriptions fetching is the real fix for your setup, and it's now tracked as #4 with the design written up. It's deliberately opt-in behind a flag, because fetching a document at run time means a remote file gets to decide where credentialed requests are sent. I'm also looking at an explicit openapi option for the debug launch config, since the debugger currently has no equivalent of the CLI's --openapi — noted on #4 as well.

Sorry for the round trip — your reports have been genuinely useful, and both of these were things nobody would have found without a careful tester.

[erwinkramer]

Looks like some good progress, thanks @strefethen, I now have the output channel for Arazzo in VS Code and it confirms your observations as well, so the current limitations are clear now. I guess the scope has steered away from my initial issue here, so maybe this can be closed now, but that's up to you.