-
Notifications
You must be signed in to change notification settings - Fork 447
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.
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
[LanguageWorker][Debugging]Function Host fails to restart language worker process on file edit if debugger is attached #3543
Comments
The root cause is issue #3415 |
Are you seeing this when you are changing file and saving it while the debugger is attached? |
Yes, that's exactly where I'm seeing the issue |
I'm also seeing this issue. |
Any update on when this'll be fixed? Makes it hard to follow a real flow of work |
For anybody who may have an interest in how to get a decent workflow up and running in VSCode until this issue is resolved I've put the following together to allow me to automatically start/stop the functions host when I launch the debugger. launch.json
tasks.json
functions_host_background.sh
You need tmux, but it makes life bearable.. Add the presentation options to your tasks to keep them out of sight. I couldn't use the compound key because of this bug: microsoft/vscode#52737 |
I have the same issue, and am hoping this will be fixed soon. |
I have the same issue... Please fix this asap... |
Adding a P1 as in addition to 'expectation' from JavaScript develop experience, believe it's needed for placeholders |
Guys do we have any solution yet, I have the same error and on prod side, working with I/O operations including creating new multiline js files in a different folder from the functions keeps restarting the host. |
@Wankishh - what's the scenario you are creating js files for? From our perspective this is an issue that affects people debugging their local code and not a production issue. Remember that function invocations should be regarded as stateless. If you are trying to preserve state between function invocations, you should explore Durable Functions. |
hi! I'm also experiencing this on MacOS with Python functions, any info available on Python files? |
@jeffhollan the work to address this will be tracked by #3415. I'm assigning a P1 to that issue now so it will be properly triaged, but we should consider closing this as a duplicate as well. |
I may be way off but I found this works with tsc -w so that changing the code does not kill the process and the debugger remains attached (just not with workspaces where the debugger does not attach):
I've been using this config for a while, not sure how I stumbled on it but it works quite well, F5 in vscode then run tsc -w in a terminal to ensure the code live updates as I change it (shouldn't have to do that with javascript). As I mentioend here: microsoft/vscode-azurefunctions#1517 the only issue is the vscode debugger will not attach to it if the proejct is running in a workspace so I'm forced to run the azure functions in a seperate vscode instance. |
Is there any follow up? |
I can confirm that this is still happening. ETA on fix, devs? |
this is a surprisingly bad developer experience, which is weird, because the vs extensions seems polished otherwise. But having to kill the process all the time is just annoying. |
I wanted to drop this info here as I have arrived at a mostly workable solution that allows me to use a Workspace with multiple Typescript function apps. The only downside is that when a Function app recompiles it does drop the debugger, but it's only a matter of a couple of seconds to reattach it based on all the configs below. I am using an npm package named Here are the configs I'm using and I would be interested to see if anyone can improve on them. workspace config file: {
"folders": [
{
"name": "project-one",
"path": "project-one"
},
{
"name": "project-two",
"path": "project-two"
}
],
"settings": {
"debug.internalConsoleOptions": "neverOpen"
},
"launch": {
"configurations": [],
"compounds": [
{
"name": "Workspace - Attach all functions",
"configurations": [
"Attach Project-One Functions",
"Attach Project-Two Functions"
]
},
{
"name": "Workspace - Attach Project-One Functions",
"configurations": [
"Attach Project-One Functions"
]
},
{
"name": "Workspace - Attach Project-Two Functions",
"configurations": [
"Attach Project-Two Functions"
]
}
]
}
} package.json - this is essentially the same for all the Function app projects minus any actual other dependencies specific to your needs {
"name": "project-one",
"version": "1.0.0",
"description": "",
"scripts": {
"build": "tsc",
"watch": "tsc-watch --onSuccess \"func start\"",
"prestart": "npm run build && func extensions install",
"start": "func host start",
"build:production": "npm run prestart && npm prune --production",
"test": "echo \"No tests yet...\""
},
"dependencies": {
},
"devDependencies": {
"@azure/functions": "^1.2.2",
"tsc-watch": "^4.2.9",
"typescript": "^3.9.7"
}
} launch.json - notice I am setting a port here. this is important as you need to set a corresponding port in your {
"version": "0.2.0",
"configurations": [
{
"name": "Attach Project-One Functions",
"type": "node",
"protocol": "inspector",
"request": "attach",
"stopOnEntry": false,
"port": 9001,
"preLaunchTask": "npm start",
"sourceMaps": true,
"cwd": "${workspaceFolder}",
"outFiles": ["${workspaceRoot}/dist/**/*.js"],
}
]
} local.settings.json -- Notice the {
"IsEncrypted": false,
"Values": {
"NODE_OPTIONS": "--inspect=9001",
"FUNCTIONS_WORKER_RUNTIME": "node",
},
"Host": {
"LocalHttpPort": 5001,
"CORS": "*",
"CORSCredentials": false
}
} tasks.json -- this is by far the biggest departure to norms, but it works. Notice the {
"version": "2.0.0",
"tasks": [
// {
// "type": "func",
// "command": "host start",
// "problemMatcher": "$func-watch",
// "isBackground": true,
// "dependsOn": "npm build",
// },
{
"type": "shell",
"label": "npm start",
"dependsOn": "npm build",
"command": "npm run watch",
"isBackground": true,
"problemMatcher": [
{
"pattern": [
{
"regexp": ".",
"file": 1,
"location": 2,
"message": 3
}
],
"background": {
"activeOnStart": true,
"beginsPattern": ".",
"endsPattern": "Host lock lease acquired by instance ID"
}
}
],
"presentation": {
"echo": true,
"reveal": "silent",
"focus": false,
"panel": "shared",
"showReuseMessage": true,
"clear": false,
"group": "projectone"
},
},
{
"type": "shell",
"label": "npm build",
"command": "npm run build",
"dependsOn": "npm install",
"problemMatcher": "$tsc",
"presentation": {
"echo": true,
"reveal": "always",
"focus": true,
"panel": "shared",
"showReuseMessage": true,
"clear": false,
"group": "projectone"
}
},
{
"type": "shell",
"label": "npm install",
"command": "npm install",
"presentation": {
"echo": true,
"reveal": "always",
"focus": true,
"panel": "shared",
"showReuseMessage": true,
"clear": false,
"group": "projectone"
}
},
{
"type": "shell",
"label": "npm prune",
"command": "npm prune --production",
"dependsOn": "npm build",
"problemMatcher": []
}
]
} Finally and again: If you change a The caveat to this is if you have a shared folder that contains code that multiple Function apps are looking at, then if you save a |
Assigning to sprint 85 for initial investigation. |
@stefanushinardi were you planning on scheduling some time to discuss this? |
@fabiocav I was under the impression that one of the devs would take a look first, but I will schedule a time slot next to discuss the issue. Thanks! |
After a discussion with @fabiocav @anthonychu @pragnagopa and @mhoeger, we believe that the issue occurs when there is an overlap while recycling processes, that results in the new process fails to open the debugging port as it is still being held by the process that is being brought down. The current approach that we are thinking is to remove the overlapping condition when running the host in development environments. |
Didn't get much time to work on this larger item with being on-call, pushing to next sprint. Apologies all, still definitely a priority :) |
Work for this is currently in progress, but we expect completion to happen next sprint. Updated the target to reflect that. |
This issue is resolved on the azure-functions-host side with host versions > 3.0.15149 (currently, this means our next release). However, this will not automatically enable a continuous debugging experience on file change. Changes also need to be made to the VS Code Extension, and those can be tracked here: microsoft/vscode-azurefunctions#781 In addition to a resolution for microsoft/vscode-azurefunctions#781, for Python functions, this change needs to be made: Closing as issue described in title, "Function Host fails to restart language worker process on file edit if debugger is attached," is resolved. |
I'm launching the debugger from VSCode. The run time is v2, and language is Node.js.
Every time I make a change to the file, the debug process crashes and I have to start the function again, as well as the debug session.
I'm on Windows!
Repro steps
Expected behavior
I don't expect the function runtime to crash.
Here's a sample log from when it happens:
The text was updated successfully, but these errors were encountered: