Core tools not responding to ctrl-C

[mattchenderson]

Version

4.0.6821 on Windows (and 4.0.6610 on Mac)

Description

The core tools doesn't seem to be responding properly to terminate commands anymore. Observed both on Windows and Mac. Instead, it just hangs.

This might be a duplicate of #4268, but the attempted connection to Azurite is not present in my repros.

I don't know if other environment factors are present that would influence this, but seeing it across users and OSes makes me think there is something surprising at play.

Steps to reproduce

Func start -> Ctrl+C

[paulyuk]

+1, I see this even on most basic HTTP example. I observe this error after waiting some time (30s?)

^C[2025-04-10T18:02:13.733Z] Host did not shutdown within its allotted time.
[2025-04-10T18:02:13.749Z] The Azure Storage connection string is either empty or invalid. Unable to record diagnostic events, so the diagnostic logging service is being stopped.
[2025-04-10T18:02:13.749Z] Azure.Data.Tables: Value cannot be null. (Parameter 'connectionString').
[2025-04-10T18:02:13.749Z] Unable to get table reference. Aborting write operation.

[robdmoore]

+1 myself and my colleagues are seeing this across Mac and Windows, super frustrating. They sit there hanging for 1-2 mins before finally quitting.

[liliankasem]

Given we start the host directly (as a task) and not through a child process, we don't kill the process but just signal the host to shutdown (we can see that with the log Host startup operation has been canceled)

Azure Functions Core Tools
Core Tools Version:       4.0.7512 Commit hash: N/A +8be8cc84f6ad64c784e083bf4da7fa381bdd3449 (64-bit)
Function Runtime Version: 4.1040.300.25317

^C[2025-07-15T22:44:19.479Z] Detaching gRPC logging due to exception.
[2025-07-15T22:44:19.518Z] Language Worker Process exited. Pid=74596.
[2025-07-15T22:44:19.518Z] python3 exited with code 130 (0x82). asyncio.exceptions.CancelledError.
[2025-07-15T22:44:24.383Z] Host startup operation has been canceled

<long pause>

[2025-07-15T22:44:24.398Z] We couldn’t initialize the Table Storage Client using the 'AzureWebJobsStorage' connection string. We are unable to record diagnostic events, so the diagnostic logging service is being stopped. Please check the 'AzureWebJobsStorage' connection string in Application Settings.
Value cannot be null. (Parameter 'provider')

I don't know why the host takes so long to shut down now, that is a problem to investigate with the host itself.

A quick fix here would be to update the cancel key event handler to just kill the process aggressively via something like:

Process.GetCurrentProcess().Kill();

But I think this breaks the behaviour/expectation of graceful shut downs that we have today? What do you think @mattchenderson

Edit: offline sync: we could DI our own app lifetime into the host and that could help us shut down gracefully - if we're still slow it likely is a host bug.

Edit2: I've narrowed down the issue to PendingItem in the host.

https://github.com/Azure/azure-functions-host/blob/a20b3070a3246578dd3d2a55f2f23266d484cdf5/src/WebJobs.Script.Grpc/Channel/GrpcWorkerChannel.cs#L1748

Cancellation tokens are not passed through and when we hit Ctrl+C and trigger the application stopping lifetime event, nothing happens because we are either waiting for a response from the worker (which never happens in this state since we kill the channel), or until timeout. The timeout is set to 1 minute and that's why it often takes a minute for the host to shut down (if the host is stopped during startup). I think this might be the same culprit for when the host is shut down when it's running as well but tbd.

[liliankasem]

Okay looks like there are two things attributing to the increased shut down period, both from the host.

1. The worker init task is blocking (same issue I mention in the comment above). If a worker crashes or exits immediately after startup, then the GrpcWorkerChannel.StartWorkerProcessAsync will block on _workerInitTask.Task until it eventually times out (60s).

2. Diagnostic events table initialization is blocking and takes 6 seconds, I added some logs to illustrate this

[2025-07-18T16:57:44.828Z] Job host stopped
[2025-07-18T16:57:44.843Z] Host shutdown completed.
[2025-07-18T16:57:44.847Z] Starting DiagnosticEventTableStorageRepository.TableClient initialization...
<6 seconds later>
[2025-07-18T16:57:50.662Z] Stopping the flush logs timer.
[2025-07-18T16:57:50.662Z] We couldn’t reach the Table service endpoint specified in the 'AzureWebJobsStorage' setting. We are unable to record diagnostic events, so the diagnostic logging service is being stopped. Please confirm network connectivity and endpoint accessibility.
[2025-07-18T16:57:50.662Z] Azure.Core: Connection refused (127.0.0.1:10002). System.Net.Http: Connection refused (127.0.0.1:10002). System.Net.Sockets: Connection refused.
[2025-07-18T16:57:50.662Z] DiagnosticEventTableStorageRepository.TableClient initialization completed. Duration: 5815 ms

For # 1 there is a PR for the fix in the host that is in progress: Azure/azure-functions-host#10937

For # 2, we need to fix this in the host (I'll open an issue), but I think we can also disable diagnostic events in the CLI entirely as it's not anything we need or use in local dev.

I also have a PR coming that will force exit on a second Ctrl+C - just as a backup.