A bug open since 2022, fixed with one guard and two regression tests.
简短回答
When okteto destroy ran, it updated the dev environment's ConfigMap with a status but no manifest, which overwrote the stored yaml field with an empty value. If the destroy then failed, a retry no longer knew which destroy commands to run. The fix only writes the yaml field when the caller actually provides manifest bytes. It was merged as PR #5171 and closed issue #3284.
The problem
Okteto lets developers build and run applications directly in a Kubernetes cluster. Each deployed dev environment has a ConfigMap that stores its status and its manifest. Issue #3284, opened in December 2022, described the consequence: the manifest disappeared from the ConfigMap even when destroy failed, which "provokes that the destroy all action in the backend doesn't work properly when a retry is done as the manifest is needed to know the commands to be executed on destroy."
Root cause
From the PR description: "destroy blanks the configmap yaml field because CfgData carries no manifest". The shared updateCmap function always encoded data.Manifest, even when it was empty.
The fix
- cmap.Data[yamlField] = base64.StdEncoding.EncodeToString(data.Manifest)
+ if len(data.Manifest) > 0 {
+ cmap.Data[yamlField] = base64.StdEncoding.EncodeToString(data.Manifest)
+ }Two regression tests back it up. Test_updateCmapKeepsManifestWhenNotProvided covers the pipeline function, and TestDestroyWithErrorOnCommandsKeepsManifestInConfigMap runs a destroy whose commands fail and asserts that the status becomes 错误 while the stored manifest is unchanged.
By the numbers
- Repository: okteto/okteto, 3,554 stars (Nov 3, 2026), Go, Apache-2.0
- Files changed: 3
- Lines: +107 / -1
- Commits: 1
- Opened: Sep 29, 2026. Merged: Oct 1, 2026. Time to merge: 2 days, 4 hours
- Review: approved and merged by a maintainer
How the review went
The maintainer approved with: "Thanks for the fix, @Roshan931! 🙌 You found the root cause, and the tests cover it well." They added a reminder: "Just remember git commit -s for the DCO."
Takeaways
- Partial updates should be partial. A function that writes "everything" with whatever it was given will eventually be given less than everything.
- Test the failure path. The bug only showed up when destroy failed, so the test makes destroy fail.
常见问题解答
Is the manifest still removed on a successful destroy?
The ConfigMap itself is deleted as part of a successful destroy, which is the behavior the issue asked for.
Where can I read more?
See the pull request and the original issue.
目标
Cleanup operations need to be retryable. Keeping the state a retry depends on, until the work is really done, is what makes that possible.
