Skip to content

Conversation

@jLopezbarb
Copy link
Contributor

Proposed changes

Fixes DEV-1046

  • Introduced a new constant for the ticker duration during the destruction process.
  • Improved the waitForNamespaceDestroyAllToComplete method to ensure comprehensive checks for resource destruction.
  • Added a new checkAllResourcesDestroyed method to verify that all resources, including configmaps, are properly removed after the destruction operation.

How to validate

  1. Run okteto destroy --all several times and check that it always finishes

CLI Quality Reminders 🔧

For both authors and reviewers:

  • Scrutinize for potential regressions
  • Ensure key automated tests are in place
  • Build the CLI and test using the validation steps
  • Assess Developer Experience impact (log messages, performances, etc)
  • If too broad, consider breaking into smaller PRs
  • Adhere to our code style and code review guidelines

- Introduced a new constant for the ticker duration during the destruction process.
- Improved the waitForNamespaceDestroyAllToComplete method to ensure comprehensive checks for resource destruction.
- Added a new checkAllResourcesDestroyed method to verify that all resources, including configmaps, are properly removed after the destruction operation.

This refactor aims to enhance the reliability and clarity of the namespace destruction process.

Signed-off-by: Javier Lopez <[email protected]>
@jLopezbarb jLopezbarb requested a review from a team as a code owner October 6, 2025 15:33
@codecov
Copy link

codecov bot commented Oct 6, 2025

Codecov Report

❌ Patch coverage is 0% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 48.59%. Comparing base (50cabeb) to head (31cdd8e).
⚠️ Report is 5 commits behind head on master.

❌ Your patch status has failed because the patch coverage (0.00%) is below the target coverage (60.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #4794      +/-   ##
==========================================
- Coverage   48.60%   48.59%   -0.02%     
==========================================
  Files         364      364              
  Lines       30428    30438      +10     
==========================================
  Hits        14791    14791              
- Misses      14461    14471      +10     
  Partials     1176     1176              
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

for _, cfg := range cfgList.Items {
for l := range cfg.GetLabels() {
if _, ok := resourcesLabels[l]; ok {
return fmt.Errorf("namespace destroy all failed: some resources where not destroyed")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should change the logs then. Before, this was running when the destroy operation in theory finished. So, when we found something, that would mean that something wasn't deleted. Now, this can be executed while the job is still being executed, or at least, if an error happens, we keeps waiting in the main loop

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the logs

return nil
if err := lda.checkAllResourcesDestroyed(ctx, namespace, c); err != nil {
oktetoLog.Infof("namespace destroy all failed: %v", err)
continue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we keep within the loop in case of error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The case that after 10s the action has not been created but there are still resources destroying

…llCommand

- Updated log message in waitForNamespaceDestroyAllToComplete method to clarify the error context when checking for destroyed resources.

This change enhances the clarity of log outputs during the namespace destruction process.

Signed-off-by: Javier Lopez <[email protected]>
for _, cfg := range cfgList.Items {
for l := range cfg.GetLabels() {
if _, ok := resourcesLabels[l]; ok {
return fmt.Errorf("namespace destroy all failed: some resources where not destroyed")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return fmt.Errorf("namespace destroy all failed: some resources where not destroyed")
return fmt.Errorf("namespace destroy all failed: some resources were not destroyed")

Signed-off-by: Javier Lopez <[email protected]>
Copy link
Member

@ifbyol ifbyol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is still one case where this might get stuck. If we don't detect the transition to DestroyingAll, the job finishes and some resource is still in the namespaces (because something failed), the command would be stuck til timeout.

I think it is fine, as it shouldn't be a common scenario, and it would require broader changes, so for now, this is fine

for _, cfg := range cfgList.Items {
for l := range cfg.GetLabels() {
if _, ok := resourcesLabels[l]; ok {
return fmt.Errorf("some resources where not destroyed")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return fmt.Errorf("some resources where not destroyed")
return fmt.Errorf("some resources were not destroyed")

- Updated the error message in checkAllResourcesDestroyed method to fix the typo "where" to "were" for improved clarity.

Signed-off-by: Javier Lopez <[email protected]>
@jLopezbarb jLopezbarb merged commit 886a740 into master Oct 14, 2025
13 of 14 checks passed
@jLopezbarb jLopezbarb deleted the jlo/fix-destroy-all-job-race-condition branch October 14, 2025 08:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants