-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TF doesn't report underlying error messages up to console - get '<nil>' instead #6796
Comments
I have seen the same behavior when App Service Plan (not ASE) provisioning or scaling out failed due to lack of capacity. |
I have experienced same issue when applying a
|
Thanks for opening this issue. After checked, seems there is no error message in response when it failed to provision app service plan. So filed an issue on Azure/azure-rest-api-specs#10210 |
I got this sort of scenario, as well. Turning TF_LOG=TRACE, found this was the root:
I'd prefer to see this error, rather than have it buried under "Service returned an error. Status= " :) Also, FWIW, the URL report for my error is wrong. So, insult + injury. :D |
Just ran into this on v2.39.0. If I do a standard $ terraform apply
...
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
azurerm_function_app.func: Creating...
azurerm_function_app.func: Still creating... [10s elapsed]
Error: web.AppsClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=<nil> <nil>
on main.tf line 36, in resource "azurerm_function_app" "func":
36: resource "azurerm_function_app" "func" { If I run again with debug logs, I get a very descriptive error message from azure as JSON in the logs $ TF_LOG=DEBUG terraform apply
... much more output...
2020-12-24T10:22:16.285-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.39.0_x5: $JSON_ERROR_MESSAGE
2020/12/24 10:22:16 [DEBUG] azurerm_function_app.func: apply errored, but we're indicating that via the Error pointer rather than returning it: web.AppsClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=<nil> <nil>
... much more output ... Extracting that {
"Code": "Conflict",
"Message": "There was a conflict. AlwaysOn cannot be set for this site as the plan does not allow it. For more information on pricing and features, please see: https://aka.ms/appservicepricingdetails ",
"Target": null,
"Details": [
{
"Message": "There was a conflict. AlwaysOn cannot be set for this site as the plan does not allow it. For more information on pricing and features, please see: https://aka.ms/appservicepricingdetails "
},
{
"Code": "Conflict"
},
{
"ErrorEntity": {
"ExtendedCode": "01020",
"MessageTemplate": "There was a conflict. {0}",
"Parameters": [
"AlwaysOn cannot be set for this site as the plan does not allow it. For more information on pricing and features, please see: https://aka.ms/appservicepricingdetails "
],
"Code": "Conflict",
"Message": "There was a conflict. AlwaysOn cannot be set for this site as the plan does not allow it. For more information on pricing and features, please see: https://aka.ms/appservicepricingdetails "
}
}
],
"Innererror": null
} I think this may have been the cause of #1271. |
I am going to close this because the If this is still an issue with |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Terraform Version info
Terraform v0.12.24
I am trying to build an Azure App Service Environment with a Linux App Service Plan in it.
This is proving to be difficult, as the same syntax one uses to define a Linux ASP:
and that which works for a Windows ASP in the ASE:
don't seem to work:
However, the point of this issue is to focus on the developer experience when working w/ this.
Here's what I get from the command line
tf apply
:Yet the underlying DEBUG output shows:
Which is infinitely more useful than what the console reported back.
We should be reporting this message content back up instead of forcing devs to set env vars and parse logs to find the real problem.
The text was updated successfully, but these errors were encountered: