Home › Azure (Functions / Bicep) › Azure Functions AGENTS.md

Azure Functions AGENTS.md

AGENTS.md for Azure Functions apps: current programming models, local Core Tools runs, idempotent triggers, managed identity, configuration, and Durable Functions rules.

AGENTS.mdAzure (Functions / Bicep)

Copy AGENTS.md

How to use

Save this as AGENTS.md in your repository root, commit it, and your agent will pick it up automatically. Edit the commands to match your project.

Note: Review and test before use. Provided as is, without warranty. See Terms.

# AGENTS.md: Azure Functions

## Commands
- Local run: `func start` (Azure Functions Core Tools); storage emulation with Azurite (`npx azurite` or the repo's compose file).
- Build/test with the language's normal commands (`dotnet test`, `npm test`, `pytest`).
- Never run `func azure functionapp publish` or `az` commands that change cloud resources unless asked; deployments go through CI/IaC.

## Programming model
- Use the current model for the language and don't mix models in one app: .NET isolated worker (`Program.cs` with `FunctionsApplication`/host builder), Node.js v4 (`app.http(...)`, `app.storageQueue(...)` in code, no `function.json`), Python v2 (`func.FunctionApp()` with decorators).
- One function per file/class, named for the trigger and purpose (`ProcessOrderQueue`). Function code is thin: parse input, call a service, return output.

## Triggers and reliability
- Queue, Service Bus, Event Hubs and Event Grid triggers retry and can deliver twice: handlers must be idempotent (dedupe on message/event ID). Let poison messages go to the poison/dead-letter queue instead of catching and dropping them.
- HTTP functions validate input and return proper status codes; set `authLevel` deliberately (`function`/`admin`, or anonymous behind API Management/Easy Auth).
- Timer triggers must tolerate overlap and missed runs; keep the CRON in app settings if environments differ.
- Keep executions short; long work goes to queues or Durable Functions.

## Durable Functions
Orchestrators must be deterministic: no `DateTime.Now`/`Date.now()`, random, network or IO calls inside them; use the context's current time and call activities for side effects. Change orchestrator code with versioning in mind (in-flight instances replay old history).

## Config and security
- Settings come from app settings/environment; `local.settings.json` is gitignored and holds only local values.
- Use managed identity with identity-based connections (`<CONN>__fullyQualifiedNamespace`, `__serviceUri`) instead of connection strings where supported; secrets via Key Vault references.
- Reuse clients (HTTP, SDK clients) as singletons via DI; never create one per invocation.
- Log with structured properties through the host logger (Application Insights); no secrets or full payloads with personal data.