Skip to content

Downgrade worktree remove fallback log to INFO - #665

Merged
jwbron merged 1 commit into
mainfrom
egg/downgrade-worktree-remove-log
Feb 14, 2026
Merged

Downgrade worktree remove fallback log to INFO#665
jwbron merged 1 commit into
mainfrom
egg/downgrade-worktree-remove-log

Conversation

@james-in-a-box

Copy link
Copy Markdown
Contributor

Summary

  • Downgrade the "Git worktree remove failed, cleaning up manually" log from WARNING to INFO

Context

When a container is torn down, Docker unmounts the /dev/null bind mount over the worktree's .git file. Depending on timing, git worktree remove may run before the mount is fully cleaned up, causing git to report "is not a working tree". The fallback path handles this correctly via surgical cleanup (shutil.rmtree + admin dir removal), so the worktree is always fully removed.

Since this is an expected race condition with successful recovery, WARNING is unnecessarily noisy. INFO is the appropriate level.

Issue: none

Test plan:

  • Verify the log level change in gateway/worktree_manager.py:513
  • Existing tests in test_worktree_manager.py cover the fallback path

Authored-by: egg

@jwbron
jwbron merged commit 82ea7bd into main Feb 14, 2026
9 checks passed

@egg-reviewer egg-reviewer Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Single-line change, downgrading logger.warninglogger.info at gateway/worktree_manager.py:513.

Assessment: No issues found.

The change is correct. The fallback path at line 505 handles the git worktree remove failure deterministically via shutil.rmtree + surgical admin dir cleanup. The failure is an expected race condition (Docker unmounting /dev/null bind over .git during container teardown), not an actionable operational concern. WARNING is inappropriate for expected-and-recovered conditions; INFO is the right level.

The surrounding code is sound: ignore_errors=True on shutil.rmtree prevents secondary failures, the admin dir is resolved before the removal attempt (line 495), and the stderr from the failed git command is still captured in the INFO log for debugging if needed.

No security, correctness, or robustness concerns.

— Authored by egg

@james-in-a-box

Copy link
Copy Markdown
Contributor Author

egg review completed. View run logs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant