- Newest
- Most votes
- Most comments
The specific error TypeError: array.some is not a function indicates a structural issue within your customizations-config.yaml rather than an issue with the STNO template parameters themselves. This occurs when the LZA engine expects an array (list) for iteration but encounters a string or a single object due to formatting.
Please verify the following in your Hub template configuration:
-
Deployment Targets: Ensure that organizationalUnits, accounts, or regions are explicitly formatted as YAML lists (using leading dashes -). A common mistake is providing a single string value (e.g., organizationalUnits: Security) instead of a list.
-
Property Alignment: Check that the deploymentTargets block is correctly indented under the specific customStack or stackSet for the Hub. If the indentation is off, the LZA parser may fail to recognize the targets as an iterable collection.
-
Consistency Check: Since your Spoke templates are working, perform a side-by-side comparison of the deploymentTargets section in the Hub configuration versus the Spoke configuration. The error suggests the Hub definition is missing the list syntax required by the createMultiAccountMultiRegionStacks logic.
The "artifact" error is purely a side effect of the synthesis phase crashing before the CloudFormation templates could be generated.
Thanks Florian. The configuration blocks look the same, but ill poke around. At least now I have an idea of where to poke at. The error didnt really give me a direction, but your update has. Ill respond after a few more runs.
@Florian
I am wondering if LZA does something weird if there is a "/" in the parameters being passed through to a custom CF template? One of the parms being passed is "arn:<AWS_PARTITION>:organizations::<ORG_MANAGEMENT_ACCOUNT_ID>:organization/<ORG-ID>".
I moved all the parameters into the actual template file as defaults for testing [and stopped the pipeline after the Bootstrap phase] and it passed. I am now going to attempt the deploy with the above parameter in the template and some other ones in the LZA custom as parameters to test if it something to do with the /
Regarding your last comment and observation: You are likely hitting a classic YAML/LZA parsing edge case. While a / or : is generally allowed, the LZA's internal processing engine sometimes struggles if complex strings (like an ARN) aren't explicitly handled. If the parser misinterprets that string, it can corrupt the structure of the parameters block, which leads directly back to the TypeError: array.some is not a function - essentially, the engine is trying to iterate over what it thinks should be an array of parameters, but it's receiving a malformed object or string instead.
A few things to try:
-
Strict Quoting: Ensure the ARN is wrapped in double quotes in your customizations-config.yaml: parameterValue: "arn:aws:organizations::123456789012:organization/o-example"
-
Simplify the Input: If the STNO template allows it, try passing only the Organization ID (e.g., o-54321) instead of the full ARN, and use !Sub or Join inside the CloudFormation template to reconstruct the ARN.
-
Check for Hidden Tabs: Sometimes when pasting ARNs, invisible characters or tabs can sneak in, which validate-config might miss but the CDK synthesis phase will trip over.
To me, it definitely sounds like the LZA-specific mapping logic is the culprit here, especially since hardcoding it in the template worked. Let me know if quoting the parameter does the trick!
Based on the error messages you're seeing, this appears to be a CDK application failure during the customizations deployment stage. The key error "TypeError: array.some is not a function" suggests there's likely a configuration issue with how the STNO hub template parameters are being passed through LZA's customizations framework.
When troubleshooting deployment errors in LZA, the text before the generic "COMMAND_EXECUTION_ERROR" message typically indicates which resource(s) failed to deploy. The "array.some is not a function" error suggests that LZA is expecting an array format for one of the parameters, but it's receiving a different data type instead.
Since you mentioned that you've reduced the parameters to as few as possible, I'd recommend checking the following:
-
Parameter Format: Verify that any parameters you're passing to the hub template through LZA's customizations configuration are properly formatted as arrays where expected. The STNO hub template requires specific parameters like "Cognito Domain Prefix" and "Allow Listed Ranges" - ensure these are formatted correctly in your LZA configuration.
-
Configuration File Structure: Double-check your customizations-config.yaml file to ensure the stackSets or customStacks section properly defines the hub template deployment with all required parameters in the correct format.
-
Build Logs: Look earlier in the CodeBuild logs (before the generic error message) to identify the specific resource or parameter that's causing the failure. The actual failure point will provide more context about what's being misinterpreted.
-
Template Compatibility: Since the hub template deploys successfully through the CloudFormation console but fails through LZA, there may be a difference in how parameters are being passed. Consider whether any parameters need to be converted to comma-delimited lists or JSON arrays for LZA's processing.
The "no matching artifact paths found" error is likely a secondary issue resulting from the initial deployment failure, as the build process couldn't complete successfully to generate the expected artifacts.
Sources
Update the hub stack(s) - Network Orchestration for AWS Transit Gateway
Problem: Core pipeline failure - Landing Zone Accelerator on AWS
@florian
I did some messing yesterday, and it seems a bit odd. The spoke template works fine with ANs with a slash, and so do others in the Hub template, it seems to only affect the "Principals" parameter in the STNO Hub template.
For now im going to hardcode that at my end while i run the full deploy, as I was stopping the pipeline after the bootstrap. Once that is done i may go back and try to troubleshoot further. That being said, the Principals parm is our Orgz ID so that wont change regarless of region....
Relevant content
- asked a year ago
- asked a year ago
- asked 2 years ago
- asked 6 years ago

If my answer was helpful, I would appreciate it if you could mark it as the accepted answer.