Skip to content
Notifications
Clear all

Help: It's rewriting my YAML anchors into invalid, duplicated blocks.

1 Posts
1 Users
0 Reactions
31 Views
(@emilykim)
Reputable Member
Joined: 3 months ago
Posts: 349
Topic starter   [#16168]

I've been working on a complex CloudFormation template that makes extensive use of YAML anchors and aliases to avoid repetition, particularly for common IAM policy structures and security group ingress rules. When I asked an assistant to help me refactor a specific section for better readability, it completely broke the anchor references.

My original snippet used an anchor for a reusable security group ingress definition:

```yaml
Resources:
GlobalIngress: &global-ingress
Type: AWS::EC2::SecurityGroupIngress
Properties:
IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 0.0.0.0/0

AppSecurityGroupIngress1:
<<: *global-ingress
Properties:
GroupId: !Ref AppSecurityGroup

AppSecurityGroupIngress2:
<<: *global-ingress
Properties:
GroupId: !Ref AnotherSecurityGroup
```

The assistant's suggested refactor aimed to "consolidate the duplicate Properties key" and produced this:

```yaml
Resources:
GlobalIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 0.0.0.0/0

AppSecurityGroupIngress1:
Type: AWS::EC2::SecurityGroupIngress
Properties:
IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 0.0.0.0/0
GroupId: !Ref AppSecurityGroup

AppSecurityGroupIngress2:
Type: AWS::EC2::SecurityGroupIngress
Properties:
IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 0.0.0.0/0
GroupId: !Ref AnotherSecurityGroup
```

The issues introduced are:
* The anchor `&global-ingress` and the alias `*global-ingress` were removed entirely, defeating the purpose of the refactor.
* The `<<:` merge key was incorrectly handled, leading to literal duplication of the base properties block.
* The output is now prone to drift if the base ingress rule needs to change (e.g., switching from port 443 to 8443).

The assistant seemed to treat the YAML merge as a simple "copy-paste" operation rather than understanding the semantic meaning of anchors as reusable nodes. The correct behavior would have been to preserve the anchor/alias structure while perhaps cleaning up the formatting of the merge. A better refactor, if one were needed, might involve moving the anchor to a separate, non-resource map for pure property reuse, but the assistant didn't propose that.

Has anyone else encountered this type of failure when assistants attempt to "optimize" declarative configuration with references? It appears to be a fundamental misunderstanding of YAML's node identity model.

—EK


Your bill is too high.


   
Quote