[AVM CI Environment Issue]: Code=RequestContentTooLarge; Message=The request content size exceeds the maximum size of 4 MB

[darrenFrowen]

Check for previous/existing GitHub issues

• [X] I have checked for previous/existing GitHub issues

Issue Type?

Bug

Description

Hi,

A strange issue which i have never encountered before. To better learn AVM i have been converting an existing repo where i was using resource deployments to AVM. So the same repo which is now near converted is throwing up the error in the title.

Error: Code=RequestContentTooLarge; Message=The request content size exceeds the maximum size of 4 MB.

Obviously i have searched on the error and found some documentation where ADF was hitting the limit. I am wondering if its due to AVM having to load module dependencies which when expanded into ARM templates we then hit this limit. My structure is that i use a single main.bicep that contains module params that get passed to separate AVM module files. My repo is only 300KB itself.

[microsoft-github-policy-service[bot]]

[!IMPORTANT] The "Needs: Triage :mag:" label must be removed once the triage process is complete!

[!TIP] For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[AlexanderSehr]

Hey @darrenFrowen, If I understand it correctly, this is not exactly a CI issue but a general 'Solution Creation' issue based when using AVM modules, right? If the case it actually wouldn't matter if it's the local file you're using or a reference to the Bicep registry - when deploying / building the ARM template, it ends up as the JSON file which may not exceed 4 mb when being send to Azure. This is a well known limitation and the PG has long been investigating how to increase this limit.

Issues raised for this can, for example, be found here: https://github.com/Azure/bicep/issues?q=is%3Aissue+is%3Aopen+4mb Though the PG also addressed this in their community calls before.

Anyways - the question remains what you can do. We already invested heavily in decreasing the template sizes when migrating from CARML to AVM - but - at the same time the size increased again by adding new features like User-defined-types, etc. So that didn't really work out the way we may have hoped. To my knowledge, there is currently no other way than to split your main.bicep into e.g. 2 templates that are deployed one after the other. A similar limitation can hit you regarding the 800 deployments limit.

Let me also pull in some of the other maintainers in case they have another idea, cc: @ChrisSidebotham, @eriqua, @jtracey93

[darrenFrowen]

Hi @AlexanderSehr ,

Yes shortly after posting this i proceeded to split my deployments into separate network and compute deployments so two mains, deployment scripts and pipelines. Ill just wait to see if there is any response from the other maintainers then close within a day or two.