Both worker.py and scheduler.py operate on the same repo checkout at workspace_dir/<repo>. The scheduler's _review_code (scheduler.py:110-112) calls clone_repo then checkout_pr_branch, while work_on_issue (worker.py:29-30) calls clone_repo then create_branch — all on the same filesystem path. If the scheduler fires while a worker task is running, they will corrupt each other's git state.
clone_repo itself is also not safe for concurrent use: it does git checkout main && git pull on an existing repo (github.py:174-179), which will fail or cause corruption if another process is mid-operation.
Fix: Use per-repo asyncio locks to serialize git operations, or use separate working directories for each operation (e.g., workspace_dir/<repo>/<branch> or git worktrees). The latter approach is more robust and allows true parallelism across different tasks.
Identified by minbot code review
Both
worker.pyandscheduler.pyoperate on the same repo checkout atworkspace_dir/<repo>. The scheduler's_review_code(scheduler.py:110-112) callsclone_repothencheckout_pr_branch, whilework_on_issue(worker.py:29-30) callsclone_repothencreate_branch— all on the same filesystem path. If the scheduler fires while a worker task is running, they will corrupt each other's git state.clone_repoitself is also not safe for concurrent use: it doesgit checkout main && git pullon an existing repo (github.py:174-179), which will fail or cause corruption if another process is mid-operation.Fix: Use per-repo asyncio locks to serialize git operations, or use separate working directories for each operation (e.g.,
workspace_dir/<repo>/<branch>or git worktrees). The latter approach is more robust and allows true parallelism across different tasks.Identified by minbot code review