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

Question

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?

Answer 1

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.

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.

Answer 3

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.