Queue trigger never fires on Azure Function Flex Consumption (Python v2)

Question

Queue trigger never fires on Azure Function Flex Consumption (Python v2)

Antimatter 0

Environment

Plan: Flex Consumption
Runtime: Python 3.11, v2 programming model (decorator-based)
Region: Southeast Asia
Deployment: Azure Functions Core Tools v4 (func azure functionapp publish --build local)

Problem

A queueTrigger function never fires. A queue message has been sitting with dequeue count 0 for over 24 hours. The scale controller is not dispatching the message to any worker instance.

What I have verified

func publish correctly detects and registers the trigger: my_push_worker - [queueTrigger] ✅
syncfunctiontriggers API returns { "status": "success" } ✅
IAM roles on the storage account are all correct: Storage Queue Data Contributor, Storage Blob Data Owner, Storage Table Data Contributor ✅
AzureWebJobsStorage is correctly configured (tested both managed identity and full connection string) ✅
The function executes correctly when invoked manually via Portal Code+Test ✅
Host startup logs show my_push_worker listed under Found the following functions ✅
Storage account traces show continuous .blob.core.windows.net requests but zero .queue.core.windows.net requests — the host never polls the queue ✅

Scale config always shows:


{

  "alwaysReady": null,

  "instanceMemoryMB": 2048,

  "maximumInstanceCount": 100,

  "triggers": null

}

triggers remains null even after successful func publish and syncfunctiontriggers. The scale controller has no trigger metadata to act on, so it never wakes up the app for queue messages.

Queue trigger decorator (function_app.py):


@app.queue_trigger(

    arg_name="msg",

    queue_name="my-push-jobs",

    connection="AzureWebJobsStorage",

)

def my_push_worker(msg: func.QueueMessage) -> None:

    asyncio.run(_my_push_worker_async(msg))

Note: queue name is hardcoded as a string literal (not a variable) to ensure static analysis picks it up correctly.

host.json:


{

  "version": "2.0",

  "extensionBundle": {

    "id": "Microsoft.Azure.Functions.ExtensionBundle",

    "version": "[4.*, 5.0.0)"

  },

  "extensions": {

    "queues": {

      "maxPollingInterval": "00:00:02",

      "visibilityTimeout": "00:00:30",

      "batchSize": 16,

      "maxDequeueCount": 5,

      "newBatchThreshold": 8

    }

  },

  "functionTimeout": "00:10:00"

}

Question

Is there a known issue with Flex Consumption + Python v2 where syncfunctiontriggers succeeds but triggers in the scale config remains null, causing queue triggers to never fire? Is there an additional step required to register queue trigger metadata with the Flex Consumption scale controller?

Rakesh Mishra 9,420 Reputation points Microsoft External Staff Moderator

2026-05-22T18:29:21.0233333+00:00
Hi Antimatter,

Thank you for sharing the code snippet. Looking at your queue trigger definition, there are two critical areas that frequently cause silent failures or trigger-sync issues on the Flex Consumption plan: the connection reference and the asynchronous implementation.

1. The AzureWebJobsStorage Connection in Flex Consumption: In the traditional Consumption plan, AzureWebJobsStorage is implicitly handled as a default connection string by the host. However, the Flex Consumption plan is heavily optimized for secure, identity-based connections and handles networking/scaling differently.

Since you have explicitly set connection="AzureWebJobsStorage", you must ensure this exact setting exists and is formatted correctly in your Function App's Environment Variables.

If you are using an Azure Storage connection string, ensure there is an app setting named AzureWebJobsStorage containing the full connection string.

If you are using Managed Identity (the recommended approach for Flex Consumption), you need an environment variable named AzureWebJobsStorage__queueServiceUri pointing to your storage account (e.g., https://<storage_account>.queue.core.windows.net).

Your Function App's managed identity must also be assigned the Storage Queue Data Message Processor role on that storage account.

If this connection is missing, misconfigured, or lacks IAM permissions, the scale controller cannot access the queue to read metadata, resulting in the triggers: null behavior and the function never firing.

2. Native Async Support (The asyncio.run Anti-Pattern): You are defining a synchronous handler (def my_push_worker) and manually invoking an event loop using asyncio.run(). This is an anti-pattern in Azure Functions. The Python worker manages its own thread pool and event loop. Manually creating a new event loop inside a synchronous thread can lead to thread-pool exhaustion, worker crashes, or deadlocks, which disrupts the host's ability to process events.

The Azure Functions Python worker natively supports asynchronous execution. You should define your trigger directly as a coroutine using async def.

From official Microsoft documentation:

"When you write a function in Python, you can write it as an asynchronous coroutine... The Azure Functions Python worker natively supports asynchronous execution. Asynchronous Python functions can help to improve the performance of your application by allowing it to process other tasks while waiting for I/O operations to complete."

Reference: Improve throughput performance of Python apps in Azure Functions

Here is how your code should be refactored:

import azure.functions as func import logging app = func.FunctionApp() @app.queue_trigger( arg_name="msg", queue_name="my-push-jobs", connection="AzureWebJobsStorage" ) async def my_push_worker(msg: func.QueueMessage) -> None: logging.info('Processing message: %s', msg.get_body().decode('utf-8')) # Natively await your asynchronous worker instead of using asyncio.run() await _my_push_worker_async(msg)

Please let me know if it works and share your findings.

Note: This response is generated with the help of AI systems.
Antimatter 0 Reputation points

2026-05-23T03:00:56.22+00:00
Thanks for your advice. Yes there is environment variable set to AzureWebJobsStorage containing full connection string. I have removed anti pattern code (I actually started with async def and switched to asyncio.run out of desperation) and redeployed, but the queue trigger still did not fire.
But once I run this, the queue was cleared right away. Does it mean the queue trigger won't work without setting at least 1 always-ready?

az functionapp scale config always-ready set \ --name mydev-func-abcdefg \ --resource-group my-Dev-RG \ --settings "function:my_push_worker=1"
Rakesh Mishra 9,420 Reputation points Microsoft External Staff Moderator

2026-05-26T00:38:26.3233333+00:00
That is a fantastic diagnostic step, and the outcome tells us exactly what is happening under the hood!

Does the queue trigger require always-ready=1?

Absolutely not. The Flex Consumption plan is specifically designed for event-driven, scale-to-zero workloads. You should not have to pay for a permanently running instance just to process queue messages.

Why did always-ready make it work?

By setting always-ready=1, you bypassed the external Azure Scale Controller. You forced an instance of your Function App to stay permanently warm. Once that instance was running, the Python worker's internal WebJobs SDK listener took over, directly polled the queue, and processed the messages.

This is actually great news: it proves that your Python code, your AzureWebJobsStorage connection string, and your storage permissions are 100% correct.

Possible Root Cause:

The issue is purely that the external Azure Scale Controller still doesn't know your trigger exists (which is why your app's scaling metadata still shows triggers: null).

When an app is scaled to zero, it relies entirely on the Scale Controller to monitor the queue and wake up the first instance (0 -> 1). Because the Scale Controller has a null trigger list, it doesn't know it should be watching your queue, so it never wakes the app up.

In Flex Consumption with Python V2, a persistent triggers: null state is almost always caused by the deployment mechanism. Traditional zip-deployments or local builds often fail to correctly parse function_app.py and register the triggers with the Azure control plane. Flex Consumption strictly requires a "Remote Build" (One Deploy) to successfully register triggers.

Next Steps:

You can resolve the trigger registration and return to a true scale-to-zero architecture by forcing a remote build deployment.

Remove the always-ready configuration so you don't incur unnecessary costs.

Redeploy your app, explicitly forcing a remote build. This ensures Azure's Kudu service builds the app and successfully syncs the trigger metadata to the Scale Controller.

Please try remote build and let me know if it works.
Rakesh Mishra 9,420 Reputation points Microsoft External Staff Moderator

2026-05-27T23:02:34.6366667+00:00

Hi @Antimatter , I hope you checked my last response, and it was helpful. Please do let me know if you need any further assistance on this.

2 answers

Your answer

Antimatter 0 Reputation points

2026-05-23T03:00:56.22+00:00

Thanks for your advice. Yes there is environment variable set to AzureWebJobsStorage containing full connection string. I have removed anti pattern code (I actually started with async def and switched to asyncio.run out of desperation) and redeployed, but the queue trigger still did not fire.
But once I run this, the queue was cleared right away. Does it mean the queue trigger won't work without setting at least 1 always-ready?

az functionapp scale config always-ready set \ --name mydev-func-abcdefg \ --resource-group my-Dev-RG \ --settings "function:my_push_worker=1"
Rakesh Mishra 9,420 Reputation points Microsoft External Staff Moderator

2026-05-27T23:02:34.6366667+00:00

Hi @Antimatter , I hope you checked my last response, and it was helpful. Please do let me know if you need any further assistance on this.

Answer 1

kagiyama yutaka 3,415

I think Azure does not show that Flex needs always‑ready for queue triggers, and it also does not show any extra step for registering them. the safe move is remote‑build redeploy and sending a new queue message.

0 comments

Answer 2

Hello Antimatter,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Queue trigger never fires on Azure Function Flex Consumption (Python v2).

The issue should not be fixed by keeping always-ready enabled. Flex Consumption supports event-driven scale-to-zero, and always-ready instances are optional for reducing cold start latency, not a requirement for queue triggers. The strongest documented corrective path is to remove always-ready, redeploy the Python app using the supported remote build / One Deploy path, clean up AzureWebJobsStorage, and validate the queue trigger using the correct diagnostics. - https://learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-plan, https://learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-how-to

Using local build for a Python Flex Consumption app is not cool. Microsoft’s Python deployment guidance recommends remote build, and Flex Consumption deployment guidance supports deployment through Core Tools, VS Code, Azure CLI, and One Deploy-based flows. - https://learn.microsoft.com/en-us/azure/azure-functions/python-build-options, https://learn.microsoft.com/en-us/azure/azure-functions/python-build-options

NOTE: Use the associated links for detail steps and more reading.

Regarding your questions:

Does queue trigger on Flex Consumption require always-ready?

No. Always-ready is optional. Flex Consumption supports scale-to-zero and event-driven scaling. - https://learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-plan, https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-queue-trigger

Is triggers: null proof that the queue trigger is not registered?

No. That field should not be used as the queue trigger registration signal.

Is there an extra manual trigger registration step required?

No, not when the app is deployed through supported Azure Functions deployment methods such as Core Tools, VS Code, Azure CLI, or One Deploy-based flows. - https://learn.microsoft.com/en-us/azure/azure-functions/functions-deployment-technologies, https://learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-how-to

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Share via

Queue trigger never fires on Azure Function Flex Consumption (Python v2)

2 answers

Your answer