azure-functions-dotnet-worker: Worker Process startup timeout (30 sec) prevents reliably debugging HostBuilder startup code
When launching an azure function with func start --dotnet-isolated-debug, visual studio pauses for a period of time to allow you to attach the debugger to the newly created process. This works fine.
What doesn’t work well is that if you set a breakpoint anywhere in your HostBuilder code and cross the 30 second mark, the underlying process recycles because of a timeout which kills your debug session. It makes it exceedingly difficult, if not impossible, to debug anything non-trivial.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 10
- Comments: 47 (15 by maintainers)
The fix has now been merged into the host. Just pending deployment at this point.
Keeping this open until the Core Tools version with the changes is available.
I am still getting the timeout error but only for Timer functions. When we comment out the timer function and leave the others running, debug tools work fine. Do we have a fix to this problem yet?
Yes, same issue, can no longer effectively debug and develop azure function 5. It really seems like a downgrade and tooling is always a 2nd thought. So broken.
Do you know when the fix will be released and be integrated into VS?
You shouldn’t have to touch anything here. When debugging, the tooling will extend the worker timeout automatically.
Just installed 16.10.2 released today and a new Functions project is still broken out of the box. What do you need from us to help you find and fix this issue?
I have an example visual studio .net project, with a basic set of timer functions that F5 will not work properly. #fail FunctionApp2.zip
@fabiocav it seems to be fixed. I did have to clear my storage acct, before I could get it resolved.
@fabiocav - It is fixed for me finally! I am running 3.0.3904 and I can debug again! Thank you all.
I tried some things here
Loaded the project started in 2022 into 2019 no luck Loaded the project started in 2019 into 2022 no luck Started new project using .NET Framework rather than .NET 5 in 2019 no luck Modified the crontab no luck Added RunOnStartup no luck
Running into the same issue here. Azure Function app in Visual studio 16.11.3 with .Net5 gets the “Starting worker process failed” when trying to debug the next day or after the scheduled event is past due. All dependencies are at the latest version
Workaround as mentioned (@cgronseth) is to change the cron schedule slightly. Pretty horrible debugging experience at the moment, is there a better work-around or any ETA on a fix?
I just encountered this same issue with a timer function. I found it seems to occur when it tries to fire a past due timer on startup.
For example, if I have an ncrontab expression of “0 */1 * * * *” and run it initially it runs fine. If I give it a minute and let it pass the time it should have fired I see the follow details in the debug:
It’s consistent for me that every time I let enough time to by to where it’s firing an IsPastDue execution Visual Studio hangs for a bit and the worker process start fails. I frequently see the below window while it’s trying to fire up:
I can also confirm that @cgronseth’s suggestion of changing the ncrontab expression makes it work again. I’m guessing behind the scenes this clears out the past due details so that it no longer thinks it has any past due executions.
Once you get to the point where it would need to run again, though, it begins erroring out again.
I can get around the issue by changing a bit the ncrontab value. Say going from “0 0 3 * * 0” to “0 0 4 * * 0” and F5 it again it works. BTW, I trigger the timer manually using postman trick.
@vijayrkn it’s a slightly different issue, but this fix will help with it. Though, the repro shared there seems to require additional (unexpected) steps, so I’d like to validate that. There’s some additional work we’re considering in the WebJobs SDK/Host layer to address the timer initialization issue
@ThreeSevenths the Core Tools update will happen once global deployment of the changes completes, which we estimate will happen at the end of next week (by July 30th), due to deployment restrictions. We can, however, share details on how you can use the version of Core Tools that targets that version before then, if needed.
Discussed in triage. Some design work will be required to settle on the right behavior, we’ll then open the required issues in the appropriate repos.
Thank you for opening this!
This is an instance where our debug behavior doesn’t seem to be properly applied.
@ankitkumarr this would require a host change to correctly identify the debug scenario and ensure those timeouts are not applied. We do that for a number of things and looks like this was just missed. I’ll loop in additional folks as this is likely impacting other languages as well.