quarkusio/quarkus · error · DeploymentException
Unable to deploy Azure function: ${e.getMessage()}
Error message
Unable to deploy Azure function: ${e.getMessage()} What it means
The Azure Functions deploy command wraps Azure Toolkit deployment failures (AzureToolkitRuntimeException) into a Quarkus DeploymentException with this message. The original Azure toolkit error (network, auth, quota, resource conflicts) is preserved as the cause and in the message text (with CRLF normalized). It means the actual Azure-side deployment failed, not the local packaging.
Source
Thrown at extensions/azure-functions/deployment/src/main/java/io/quarkus/azure/functions/deployment/AzureFunctionsDeployCommand.java:121
BuildProducer<DeployCommandActionBuildItem> producer) throws Exception {
if (!deployConfig.isEnabled(AZURE_FUNCTIONS)) {
return;
}
validateParameters(config, appName.getAppName());
setCurrentOperation();
AzureMessager.setDefaultMessager(new QuarkusAzureMessager());
Azure.az().config().setLogLevel(HttpLogDetailLevel.NONE.name());
initAzureAppServiceClient(config);
try {
final FunctionAppBase<?, ?, ?> target = createOrUpdateResource(
config.toFunctionAppConfig(subscriptionId, appName.getAppName()));
Path outputDirectory = output.getOutputDirectory();
Path functionStagingDir = outputDirectory.resolve(AZURE_FUNCTIONS).resolve(appName.getAppName());
deployArtifact(functionStagingDir, target);
} catch (AzureToolkitRuntimeException e) {
throw new DeploymentException("Unable to deploy Azure function: " + e.getMessage().replace("\\r\\n", "\n"), e);
}
producer.produce(new DeployCommandActionBuildItem(AZURE_FUNCTIONS, true));
}
private void setCurrentOperation() {
// Note:
// This gets rid of some these messages. Not sure why or how to remove the rest of them yet:
// default to NULL OperationContext, because operation or its action operation is null:Quarkus
try {
Method push = OperationThreadContext.class.getDeclaredMethod("pushOperation", Operation.class);
push.setAccessible(true);
OperationBase dummy = new OperationBase() {
@Override
public Object getSource() {
return null;
}
@OverrideView on GitHub (pinned to e1c734241f)
Solutions
- Read the cause chain for the underlying Azure error (auth, 409 conflict, 403, timeout)
- Re-authenticate: az login or refresh service-principal credentials in the auth file
- Check the function app name availability and subscription/resource group in the Azure portal
- Retry after resolving transient network/proxy issues
Defensive patterns
Strategy: retry
Validate before calling
// pre-flight: verify azure credentials and app name availability az account show az functionapp list --resource-group my-rg --query "[].name"
Try / catch
try {
deploy();
} catch (DeploymentException e) {
Throwable cause = e.getCause(); // AzureToolkitRuntimeException
if (isTransient(cause)) { backoffAndRetry(); } else { failWithCause(cause); }
} Prevention
- Log/persist the full cause chain of DeploymentException
- Run az login / refresh SP credentials before CI deploys
- Check function-app name availability and regional capacity pre-deploy
- Handle 409 (name taken) and 403 (auth) distinctly before retrying
When it happens
Trigger: quarkus:deploy reaches deployArtifact and the Azure SDK/Toolkit throws AzureToolkitRuntimeException — e.g. invalid credentials, app name already taken, resource group missing, quota exceeded, network failure.
Common situations: Expired Azure CLI login or service-principal credentials; function app name globally not available; wrong subscription/resource group; Azure region capacity issues; corporate proxy blocking deployment endpoints.
Related errors
- Cannot find ClassLoadingRecorder.class on classpath
- Couldn't fetch '' class from index
- Our supertype instance does not match supertype declared ar
- Unable to find handler class, make sure your deployment incl
- Path must be set if using file auth config
AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05).
Data as JSON: /api/errors/03ac1e4e3ff502f3.
Report an issue: GitHub.