Python timer trigger does not run locally when runonstartup is set to true

[ejizba]

Originally filed by @paulbatum as Azure/azure-functions-host#5262

To summarize, seems like we need to remove the --wait flag when getting command line options for python debugging

[pragnagopa]

Copying notes from original issue:

The command line options come from the Python extension (related to microsoft/vscode-python#3121) and pretty sure we just went with the default. @DonJayamanne @brettcannon what exactly does that --wait flag do?

[brettcannon]

@pragnagopa Don doesn't work on the main extension anymore (he's on the data science side now), so no need to loop him in for debugger-related things.

Looping in @karthiknadig and @int19h to answer the question authoritatively.

[karthiknadig]

@pragnagopa --wait means that debugger will initialize and block user code execution until IDE connects to the debugger.

[pragnagopa]

Thanks @karthikananth

@EricJizbaMSFT - Having --wait is blocking python language worker initialization if a function invocation starts as soon as functions host is up and running. I recommend removing this flag.

I will prioritize fix for Azure/azure-functions-host#4384 soon.

[int19h]

I don't know the details of code organization in case of functions, but for regular scripts, if wait is not used, code starts running immediately without waiting for IDE to attach, and can run to completion, or past some breakpoint that was set at the beginning of the script. If that is not a concern here - e.g. if execution of user code is triggered separately from the process launch - then you don't need wait.

But if you do need it, but want it to run later, you have more control over things if you use the ptvsd API to enable debugging instead of using the CLI. For that, you'll need to make sure that ptvsd is importable as a module from your app, and then use ptvsd.enable_attach() to start the debug server, and ptvsd.wait_for_attach() to wait until the IDE connects. We generally recommend calling the former as early as possible during startup, so that it can enable tracing for all threads; but you can then do any other initialization before calling wait_for_attach().

[paulbatum]

@int19h thanks for sharing these details.

I recently noticed when working with @pragnagopa that the javascript debugging experience in VS code for functions would occasionally seem to allow user code to run before the debugger attached properly. It sounds like we might have been getting this behavior because there is no equivalent of '--wait' used for the JavaScript case? I would caution against us making a change here that will make the F5 debugging experience harder for python users. There are definitely scenarios where we need to wait for the debugger to attach - for example hitting F5 to debug a function triggered by a prepopulated queue.

If using '--wait' will give us the best debugging experience, perhaps we need to revisit how runonstartup=true works in functions?

[pragnagopa]

In case of functions, starting a process and executing user code are separate tasks.

Issue #1492 has more details and workaround for javascript debugging exeperiece.

I believe, addressing issue Azure/azure-functions-host#4384 in function host will provide a more deterministic way for VS-Code to attach debugger with and without runonstartup=true