Skip to content

chore: add VS Code Azure Functions debug setup for gofuncapp #9315

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Fernadoteixeira wants to merge 6 commits into
base: main
Choose a base branch
from
Open

chore: add VS Code Azure Functions debug setup for gofuncapp #9315

Show file tree
Hide file tree
Changes from 5 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
10a15d4
chore(vscode): add Azure Functions debug setup for gofuncapp sample
Fernadoteixeira Jul 27, 2026
86c0274
fix(vscode): align gofuncapp debug config to Go sample
Fernadoteixeira Jul 27, 2026
a1bc3ea
fix(vscode): align Go Functions debug profile and matcher
Fernadoteixeira Jul 27, 2026
9034ecd
fix(vscode): use explicit cmd.exe in Windows task for gofuncapp fixture
Fernadoteixeira Jul 27, 2026
2082dc8
fix(vscode): add debug cleanup task and remove deploy settings
Fernadoteixeira Jul 27, 2026
d00ac9e
chore(vscode): add cspell.yaml entry-point for VS Code spell check
Fernadoteixeira Jul 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions .vscode/extensions.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,8 @@
// for the documentation about the extensions.json format
"recommendations": [
"streetsidesoftware.code-spell-checker",
"redhat.vscode-yaml"
"redhat.vscode-yaml",
"ms-azuretools.vscode-azurefunctions",
"golang.go"
Comment thread
Fernadoteixeira marked this conversation as resolved.
]
}
}

@jongio Jon Gallant (jongio) Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This drops the trailing newline on a file that otherwise had one. tasks.json and the new .funcignore don't have one either. Worth adding back so the diff stays to the intended change.

15 changes: 11 additions & 4 deletions .vscode/launch.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,24 +9,31 @@
// to ensure git tracks changes to this file again.
"version": "0.2.0",
"configurations": [
// If you set `AZD_DEBUG=true` in your environment, `azd` will pause early in start up and allow you to attach
// to it. Use the Attach to Process configuration and pick the corresponding `azd` process.
{

@jongio Jon Gallant (jongio) Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This drops the comment that explained AZD_DEBUG=true, which is how you get azd to pause at startup so "Attach to Process" has something to attach to. That isn't discoverable from the config itself. The comment above "Debug azd cli" was removed too. Can both go back? They're unrelated to the Functions work.

"name": "Attach to Process",
"type": "go",
"request": "attach",
"mode": "local",
"processId": "${command:pickGoProcess}"
},
// This will launch azd cli (starting from cli/azd/main.go), under the debugger.
{
"name": "Debug azd cli",
"type": "go",
"request": "launch",
"mode": "debug",
"program": "${workspaceFolder}/cli/azd",
"args": "${input:cliArgs}",
"console": "integratedTerminal",
"console": "integratedTerminal"
},
{
"name": "Attach to Go Functions",
"type": "go",
"request": "attach",
"mode": "remote",
"host": "127.0.0.1",
"port": 2345,
"preLaunchTask": "func: host start",
"postDebugTask": "cleanup gofuncapp debug"

@jongio Jon Gallant (jongio) Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

postDebugTask only fires when a debug session ends, and preLaunchTask gates whether that session ever starts. func: host start carries dependsOn: prepare gofuncapp debug, so the order on a normal F5 is: write go.mod and go.sum into the fixture, start the host, then attach.

On the Core Tools version I tested, the second step never completes, it sits on the worker runtime prompt. No session means no postDebugTask, so the first F5 leaves go.mod behind and go vet ./test/functional/ stops compiling until someone deletes it by hand.

That makes this more than the startup-failure path already raised on this line. It's the path you get by following the config exactly as written. Cleanup hung off the debug lifecycle can't cover setup that happens before the session exists.

Copying the sample into a temp directory and pointing cwd there would leave the fixture untouched no matter where the flow stops.

}
],
"inputs": [
Expand Down
6 changes: 5 additions & 1 deletion .vscode/settings.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,5 +4,9 @@
"-timeout",
"30m"
],
"aspire.enableSettingsFileCreationPromptOnStartup": false
"aspire.enableSettingsFileCreationPromptOnStartup": false,
"azureFunctions.projectSubpath": "cli/azd/test/functional/testdata/samples/gofuncapp",

@jongio Jon Gallant (jongio) Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These three are committed workspace settings, so every contributor with the Functions extension installed gets azure-dev treated as a single Go Functions project rooted at a test fixture. The repo also has samples/funcapp, so picking gofuncapp here is arbitrary for anyone not working on this specific sample.

Could these move into a .vscode/ folder inside the gofuncapp sample? That keeps the config next to the thing it configures and off everyone else's workspace.

"azureFunctions.projectLanguage": "Go",
"azureFunctions.projectRuntime": "~4",
"debug.internalConsoleOptions": "neverOpen"

@jongio Jon Gallant (jongio) Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This applies to every debug session in the repo, including the existing "Debug azd cli" config, so anyone debugging azd stops getting the debug console. internalConsoleOptions is valid as a per-configuration attribute, so it can live on the new Go Functions entry in launch.json instead of here.

}
50 changes: 50 additions & 0 deletions .vscode/tasks.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
{
"version": "2.0.0",
"tasks": [
{
"label": "prepare gofuncapp debug",
"type": "shell",
"windows": {
"command": "cmd.exe /c \"if not exist go.mod copy /Y go.mod.txt go.mod >nul && if not exist go.sum copy /Y go.sum.txt go.sum >nul\""
Comment thread
Fernadoteixeira marked this conversation as resolved.

@jongio Jon Gallant (jongio) Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cmd.exe folds && into the if body, so this parses as if not exist go.mod ( copy ... && if not exist go.sum copy ... ). When go.mod already exists the whole line is skipped and go.sum never gets created, so func host start then fails on a missing checksum.

Line 36 has the same shape with &: if go.mod is already gone but go.sum is still there, go.sum never gets deleted.

I reproduced both on Windows. Wrapping each if in parens fixes the parse and keeps the current "don't clobber what I didn't create" behavior:

Suggested change
"command": "cmd.exe /c \"if not exist go.mod copy /Y go.mod.txt go.mod >nul && if not exist go.sum copy /Y go.sum.txt go.sum >nul\""
"command": "cmd.exe /c \"(if not exist go.mod copy /Y go.mod.txt go.mod >nul) & (if not exist go.sum copy /Y go.sum.txt go.sum >nul)\""

Line 36 needs the same treatment: cmd.exe /c "(if exist go.mod del go.mod) & (if exist go.sum del go.sum)".

This is separate from the ownership question already raised on line 33.

},
"osx": {
"command": "[ -f go.mod ] || cp go.mod.txt go.mod; [ -f go.sum ] || cp go.sum.txt go.sum"
},
"linux": {
"command": "[ -f go.mod ] || cp go.mod.txt go.mod; [ -f go.sum ] || cp go.sum.txt go.sum"
},
"problemMatcher": [],
"options": {
"cwd": "${workspaceFolder}/cli/azd/test/functional/testdata/samples/gofuncapp"
}
},
{
"type": "func",
"label": "func: host start",
"command": "host start",

@jongio Jon Gallant (jongio) Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I installed Core Tools 4.5.0 and ran func host start against a copy of this fixture with go.mod/go.sum copied in exactly the way the prepare task does. It never starts the host, it stops on an interactive prompt:

Use the up/down arrow keys to select a worker runtime:
1. dotnet (isolated worker model)
2. dotnet (in-process model)
3. Node
4. Python
5. Powershell
6. Custom

Two things behind that. The fixture has no local.settings.json, so FUNCTIONS_WORKER_RUNTIME is unset and Core Tools falls back to asking. And there's no Go entry in that list. Go runs through Custom, which needs a customHandler block in host.json with a defaultExecutablePath plus a build step to produce the binary, and gofuncapp/host.json only carries version and extensionBundle.

As a preLaunchTask with isBackground: true that prompt never gets answered, so the task hangs, Delve never listens on 2345, and "Attach to Go Functions" has nothing to attach to.

Did this launch for you locally? If it did, knowing your Core Tools version would help, because it doesn't on 4.5.0. Otherwise this needs a local.settings.json with the worker runtime plus host.json and build wiring for the Go worker before the profile can do anything.

"problemMatcher": "$func-golang-watch",
"isBackground": true,
"dependsOn": "prepare gofuncapp debug",

@jongio Jon Gallant (jongio) Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dependsOn means this task creates go.mod in the fixture, but cleanup only runs as postDebugTask on the launch config. Anything that runs this task without a debug session leaves the file behind: picking "func: host start" from Run Task, the Functions extension starting the host on its own, or terminating the task instead of stopping the debugger.

That matters more than it looks. With go.mod present:

$ go vet ./test/functional/
test\functional\cli_test.go:830:12: pattern all:testdata/samples/*: cannot embed directory testdata/samples/gofuncapp: in different module

The whole functional test package stops compiling until someone deletes it by hand, which is what the .txt suffix at up_test.go:256 exists to prevent. A leftover go.sum is harmless on its own, I checked that separately, it's go.mod that breaks the build.

cli/azd/test/functional/testdata/samples/.gitignore only carries .azure/ today, so these also show up as untracked files and can get committed by accident. Listing go.mod and go.sum there would cap the blast radius however the task gets invoked. Copying the sample to a temp dir and debugging from there would avoid the problem outright.

"options": {
"cwd": "${workspaceFolder}/cli/azd/test/functional/testdata/samples/gofuncapp"
}
},
{
"label": "cleanup gofuncapp debug",
"type": "shell",
"windows": {
"command": "cmd.exe /c \"if exist go.mod del go.mod & if exist go.sum del go.sum\""
},
"osx": {
"command": "rm -f go.mod go.sum"
},
"linux": {
"command": "rm -f go.mod go.sum"
},
"problemMatcher": [],
"options": {
"cwd": "${workspaceFolder}/cli/azd/test/functional/testdata/samples/gofuncapp"
}
}
]
}
1 change: 1 addition & 0 deletions cli/azd/test/functional/testdata/samples/gofuncapp/.funcignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
.venv

@jongio Jon Gallant (jongio) Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.venv is a Python virtualenv directory and this is a Go sample, so it won't match anything here.

azd uses .funcignore as the packaging ignore file for function apps (cli/azd/pkg/project/service_target.go:144), so this is an edit to a functional-test fixture rather than contributor tooling, which sits awkwardly with "does not change azd runtime behavior" in the description. Is it needed at all? None of the other samples ship one.