Bicep file errors are not mapped from ARM deployment errors

[alex-frankel]

Will become more important once the .bicep file extension is natively supported in Az PS/CLI commands

[alex-frankel]

To do this for powershell, we need to resolve any line number inconsistency issues. There may be other issues in CLI to resolve.

[norbusonam]

@shenglol @alex-frankel Is there a timeline for this issue? This would be helpful for ARM Template Analyzer (https://github.com/Azure/template-analyzer) to map problems back to the bicep.

[alex-frankel]

@norbusonam -- no timeline atm. TBH, it hasn't emerged as significant of an issue as we had predicted, so it is not currently high on the priority list.

[heaths]

I've run into this because of a non-obvious user error using listKeys. Since an ARM template is compiled behind the scenes, what about generating a source map like TypeScript (tsc) does when transpiling JavaScript? Took a few minutes to figure out what was wrong (once I compiled the ARM template myself it didn't take long) and, as you said, it probably doesn't happen enough to warrant a higher priority, but wanted to pass the idea along.

[WhitWaldo]

To do this for powershell, we need to resolve any line number inconsistency issues. There may be other issues in CLI to resolve.

I've generally found that the line number given in ARM errors is always 1 as though the template itself is flattened. I've been unable to find anything about what is happening with the template on Azure's side (from which to discern how to make sense of the line position it points to as the source of the error). @alex-frankel do you know of anything published in this regard?

[alex-frankel]

There is some unfortunate formatting that sometimes happens in Az PS and Az CLI as a result of the JSON libraries we use. The template is getting stripped of white space prior to being sent to ARM. What the ARM Deployments engine sees is the entire template in one line, hence this result. We have a work item to get it resolved, but it hasn't been prioritized. To be transparent, our ability to emit accurate position info in our errors is mediocre even if the template formatting is not disturbed. We need to revisit the capability entirely in order to deliver something meaningful.

[anthony-c-martin]

Another place I think this can happen is if the error occurs when the deployment engine is processing a nested template (Bicep module). I believe the deployment engine reformats nested deployments before processing them, leading to whitespace information being lost.

[oscarhermoso]

+1 for this issue - I would find it super valuable. Right now we're having conversations in our MS Teams chats like this, and support for source maps would definitely solve the issue:

[StephenWeatherford]

Simple example (don't choose a parameter file):

param location string

produces this:

4:47:25 PM: Starting deployment of /private/var/folders/xz/0qvk9_592r1f_y5l3py0m_b00000gn/T/main.bicep
4:47:25 PM: Scope specified in main.bicep -> resourceGroup
4:48:03 PM: No parameter file was provided
4:48:05 PM: Deployment failed for /private/var/folders/xz/0qvk9_592r1f_y5l3py0m_b00000gn/T/main.bicep. Deployment template validation failed: 'The value for the template parameter 'location' at line '1' and column '293' is not provided. Please see https://aka.ms/resource-manager-parameter-files for usage details.'.
Status: 400 (Bad Request)
ErrorCode: InvalidTemplate

Content:
{"error":{"code":"InvalidTemplate","message":"Deployment template validation failed: 'The value for the template parameter 'location' at line '1' and column '293' is not provided. Please see https://aka.ms/resource-manager-parameter-files for usage details.'.","additionalInfo":[{"type":"TemplateViolation","info":{"lineNumber":1,"linePosition":293,"path":"properties.template.parameters.location"}}]}}

Headers:
Cache-Control: no-cache
Pragma: no-cache
x-ms-failure-cause: REDACTED
x-ms-ratelimit-remaining-subscription-writes: REDACTED
x-ms-request-id: 70cc47a3-20c2-4610-ac55-281ee6f296cc
x-ms-correlation-request-id: REDACTED
x-ms-routing-request-id: REDACTED
Strict-Transport-Security: REDACTED
X-Content-Type-Options: REDACTED
Date: Wed, 30 Mar 2022 23:48:04 GMT
Content-Type: application/json; charset=utf-8
Expires: -1
Content-Length: 402