What happens if a function throws an exception after autoCompleteMessages has already removed the message from the queue?

With autoCompleteMessages: true, the message is completed (removed) once the function returns successfully, if an exception is thrown before the function returns, the message is NOT auto-completed and follows the Service Bus queue's normal retry/dead-letter behavior instead. The risk case is a function that completes without throwing but has a subtle bug where it doesn't correctly finish its real side effects, that message is still marked complete and removed, since Service Bus and the trigger binding have no way to know the function's actual business logic didn't fully succeed.

Does maxConcurrentCalls limit concurrency across all instances of the function, or per instance?

Per function app instance, if the Functions host scales out to multiple instances (common in a Consumption or Premium plan under load), each instance independently applies its own maxConcurrentCalls limit, meaning total concurrent message processing across the whole function app can be a multiple of the per-instance setting. Size maxConcurrentCalls with this scale-out behavior in mind, not as if it were a single global concurrency cap.

Can a single function execution use bindings connecting to different storage accounts or services?

Yes, each binding independently references its own connection setting (like CosmosDBConnection versus StorageConnection versus SignalRConnection in the example), there's no requirement that all bindings on one function share the same underlying account or service, this is exactly what makes multi-destination fan-out from a single trigger practical.

Azure Function Binding Builder

ComputeAzure

Build Azure Functions binding configs for triggers, input, and output bindings including Service Bus, Cosmos DB, Blob, and Queue.

Azure Functions Configuration

Build Azure Functions binding configs for triggers, input, and output bindings including Service Bus, Cosmos DB, Blob, Queue, SignalR, and SendGrid.

Required Fields

functionNamebindingsbindings[0].namebindings[0].typebindings[0].direction

{
  "functionName": "ProcessOrderQueue",
  "scriptFile": "dist/ProcessOrderQueue/index.js",
  "entryPoint": "run",
  "bindings": [
    {
      "name": "orderMessage",
      "type": "serviceBusTrigger",
      "direction": "in",
      "queueName": "orders-queue",
      "connection": "ServiceBusConnection",
      "isSessionsEnabled": false,
      "autoCompleteMessages": true,
      "maxConcurrentCalls": 16
    },
    {
      "name": "orderDocument",
      "type": "cosmosDB",
      "direction": "out",
      "databaseName": "orders-db",
      "containerName": "processed-orders",
      "connection": "CosmosDBConnection",
      "createIfNotExists": true,
      "partitionKey": "/customerId"
    },
    {
      "name": "notificationQueue",
      "type": "queue",
      "direction": "out",
      "queueName": "order-notifications",
      "connection": "StorageConnection"
    },
    {
      "name": "orderBlob",
      "type": "blob",
      "direction": "out",
      "path": "order-archives/{DateTime}-{rand-guid}.json",
      "connection": "StorageConnection"
    },
    {
      "name": "signalRMessages",
      "type": "signalR",
      "direction": "out",
      "hubName": "orderUpdates",
      "connectionStringSetting": "SignalRConnection"
    },
    {
      "name": "sendGridMessage",
      "type": "sendGrid",
      "direction": "out",
      "apiKey": "SendGridApiKey",
      "from": "orders@contoso.com",
      "to": "{customerEmail}"
    }
  ],
  "retry": {
    "strategy": "exponentialBackoff",
    "maxRetryCount": 5,
    "minimumInterval": "00:00:10",
    "maximumInterval": "00:15:00"
  }
}

Generated Output

Output will appear here...

About This Tool

Build an Azure Functions function.json binding configuration mixing a trigger binding (serviceBusTrigger, direction in) with multiple output bindings (cosmosDB, queue, blob, signalR, sendGrid, direction out), each binding type carrying its own type-specific properties rather than a shared schema. maxConcurrentCalls on the serviceBusTrigger controls how many messages this function instance processes in parallel, a value too high for a function doing meaningful per-message work can overwhelm downstream dependencies (a database connection pool, a rate-limited external API) that weren't sized for that level of concurrency, while autoCompleteMessages: true means the trigger auto-completes (removes) the message from the queue once the function returns successfully, which is usually right but means a function that appears to succeed but doesn't actually finish its real side effects (a bug, not a crash) still removes the message as if it worked.

When to Use This Tool

•Setting maxConcurrentCalls to a value that matches the downstream Cosmos DB or external API's actual capacity, rather than defaulting to a high number that maximizes throughput but risks overwhelming a rate-limited or connection-pool-limited downstream dependency.
•Using multiple output bindings from one function execution (writing to Cosmos DB, publishing a notification queue message, and archiving to blob storage all from the same trigger), avoiding the need for separate functions or manual SDK calls for each destination.
•Configuring the retry policy with exponentialBackoff and bounded minimumInterval/maximumInterval, so a transient downstream failure gets retried with sensible backoff rather than either failing immediately or retrying so aggressively it compounds the downstream issue.
•Setting isSessionsEnabled to true on the serviceBusTrigger specifically when message ordering within a session (like all messages for one order ID) must be preserved, since session-enabled processing changes how the trigger dequeues and processes messages compared to non-sessioned queues.

Pro Tips

TIP

Size maxConcurrentCalls against the actual capacity of whatever the function calls downstream, remembering it applies per scaled-out instance, not as a single global cap, an aggressive setting under Consumption plan scale-out can overwhelm a downstream dependency much faster than expected.

TIP

autoCompleteMessages: true is the right default for most functions, but be aware it doesn't protect against a function that 'succeeds' without actually completing its intended side effects, that's a message silently lost from a reliability perspective, not a crash Service Bus retry logic would ever see.

TIP

Configure retry policy bounds (minimumInterval/maximumInterval) deliberately based on the downstream dependency's actual recovery characteristics, not a copy-pasted default, an interval too short compounds load on a struggling downstream service, one too long delays legitimate recovery-driven retries unnecessarily.

How It Works Under the Hood

The builder validates that functionName, bindings, and the first binding's name/type/direction resolve before accepting the JSON as a valid function.json binding manifest, the minimum the Functions runtime needs to wire up the trigger and any input/output bindings; it can't verify the referenced connection app settings (ServiceBusConnection, CosmosDBConnection, etc.) actually exist and are correctly configured, or that each binding's type-specific properties are complete and valid for that binding type, those are only surfaced when the function actually runs.

Frequently Asked Questions

What happens if a function throws an exception after autoCompleteMessages has already removed the message from the queue?: With autoCompleteMessages: true, the message is completed (removed) once the function returns successfully, if an exception is thrown before the function returns, the message is NOT auto-completed and follows the Service Bus queue's normal retry/dead-letter behavior instead. The risk case is a function that completes without throwing but has a subtle bug where it doesn't correctly finish its real side effects, that message is still marked complete and removed, since Service Bus and the trigger binding have no way to know the function's actual business logic didn't fully succeed.
Does maxConcurrentCalls limit concurrency across all instances of the function, or per instance?: Per function app instance, if the Functions host scales out to multiple instances (common in a Consumption or Premium plan under load), each instance independently applies its own maxConcurrentCalls limit, meaning total concurrent message processing across the whole function app can be a multiple of the per-instance setting. Size maxConcurrentCalls with this scale-out behavior in mind, not as if it were a single global concurrency cap.
Can a single function execution use bindings connecting to different storage accounts or services?: Yes, each binding independently references its own connection setting (like CosmosDBConnection versus StorageConnection versus SignalRConnection in the example), there's no requirement that all bindings on one function share the same underlying account or service, this is exactly what makes multi-destination fan-out from a single trigger practical.

Related Learning Guides

Azure VM Series Guide22 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.