fix(runtime): do not unmanage resource if created in AWS#252
fix(runtime): do not unmanage resource if created in AWS#252Mallikarjunadevops wants to merge 1 commit into
Conversation
Fixes issue #2849 and similar cases where a resource is successfully created in AWS, but a post-creation step (like syncSGRules or LoggingConfig) fails. Previously, any AWS API error on create flow would unmanage the resource by removing its finalizer, leaving the resource orphaned in AWS. We now check if latest != nil (which indicates creation succeeded) and only unmanage if it wasn't created.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Mallikarjunadevops The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
ack-prow
Bot
added
the
needs-ok-to-test
|
Hi @Mallikarjunadevops. Thanks for your PR. I'm waiting for a aws-controllers-k8s member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
2 participants
Fixes aws-controllers-k8s/community#2849
This PR ensures that resources are not unmanaged (by removing the finalizer) if the primary resource was successfully created in AWS (indicated by "latest != nil").
Previously, any AWS API error returned from the Create flow would unmanage the resource. This is problematic for resources with post-create hooks (like SecurityGroup egress rule sync or WebACL logging configuration). If the hook fails, the primary resource is left orphaned in AWS because the finalizer is removed, and on subsequent reconciliations the controller will either try to recreate it or fail because the name already exists.
This PR fixes this by checking if "latest != nil". If it is not nil, it means the controller explicitly returned the created resource despite a subsequent hook error, so we should keep managing it.