Elasticache controller 1.3.0 removing kmsKeyID from ReplicationGroup

[henryzhao95]

Describe the bug
A concise description of what the bug is.

I've recently updated from 0.2.5 of Elasticache ACK to 1.3.0.

I find all my ReplicationGroups are now stuck in a sync loop where kmsKeyID gets removed by the ACK, re-added by Argo CD, removed by the ACK - repeat.

Steps to reproduce
Deploy ReplicationGroup

Expected outcome
In 0.2.5, the kmsKeyID persists in the YAML
Environment

• Kubernetes version
  1.32.9
• Using EKS (yes/no), if so version?
  Yes 1.32
• AWS service targeted (S3, RDS, etc.)
  Elasticache

[github-actions]

Hello @henryzhao95 👋 Thank you for opening an issue in ACK! A maintainer will triage this issue soon.

We encourage community contributions, so if you're interested in tackling this yourself or suggesting a solution, please check out our Contribution and Code of Conduct guidelines.

You can find more information about ACK on our website.

[henryzhao95]

After turning on debug logging, I found this:

2025-12-10T05:18:13.296Z	INFO	ackrt	desired resource state has changed	{"kind": "ReplicationGroup", "namespace": "my_namespace", "name": "csec-financial-market-research-data", "account": "<account>", "role": "", "region": "ap-southeast-2", "is_adopted": false, "generation": 3591, "diff": [{"Path":{"Parts":["Spec","Engine"]},"A":"valKey","B":"valkey"},{"Path":{"Parts":["Spec","KMSKeyID"]},"A":null,"B":"arn:aws:kms:ap-southeast-2:<account>:key/<key-id>"},{"Path":{"Parts":["Spec","LogDeliveryConfigurations"]},"A":[{"destinationDetails":{"cloudWatchLogsDetails":{"logGroup":"/aws/ec2/my_org/instance"}},"destinationType":"cloudwatch-logs","logFormat":"text","logType":"engine-log"}],"B":null}]}

After renaming the engine from valKey to valkey the issue resolved itself.

The docs on https://aws-controllers-k8s.github.io/docs/api-reference#elasticache/ReplicationGroup still say the only valid value is Redis.