bug(worktrees): madt_worktrees add blocks ~120s after the git worktree add already completed #469

New issue

Open

opened 2026-09-04 17:10:04 +00:00 by hexajon · 1 comment

hexajon commented

2026-09-04 17:10:04 +00:00

Owner

madt_worktrees action=add did not return for over 120s and was moved to the background. The git work was already done almost immediately.

What I saw

The call was a plain action=add (new branch, a foreign target via dir=).
Within a few seconds, git worktree list already showed the new worktree at the right sha and branch, the directory was on disk, and there were no index locks.
The repo is small (.git is about 44M), so this is not a checkout-size cost.
The MCP call eventually completed with the normal success message. Nothing failed. It just blocked for 120s+ AFTER the git work was finished.

Read

The delay is in the wrapper's post-add step, not in git worktree add. Candidates to investigate later:

a post-add status or clean check that scans the whole tree,
an unexpected network or fetch step,
a hook,
a lock wait,
a slow enumerate over the repo or its worktrees.

Repro

Run madt_worktrees action=add on any repo. Compare when the tool returns against when git worktree list first shows the new worktree. The gap is the bug.

Acceptance

madt_worktrees add returns promptly once the git op completes.
If a post-add step is genuinely needed, it does not add many seconds, or it does not block the tool return.

`madt_worktrees action=add` did not return for over 120s and was moved to the background. The git work was already done almost immediately. ### What I saw - The call was a plain `action=add` (new branch, a foreign target via `dir=`). - Within a few seconds, `git worktree list` already showed the new worktree at the right sha and branch, the directory was on disk, and there were no index locks. - The repo is small (`.git` is about 44M), so this is not a checkout-size cost. - The MCP call eventually completed with the normal success message. Nothing failed. It just blocked for 120s+ AFTER the git work was finished. ### Read The delay is in the wrapper's post-add step, not in `git worktree add`. Candidates to investigate later: - a post-add status or clean check that scans the whole tree, - an unexpected network or fetch step, - a hook, - a lock wait, - a slow enumerate over the repo or its worktrees. ### Repro Run `madt_worktrees action=add` on any repo. Compare when the tool returns against when `git worktree list` first shows the new worktree. The gap is the bug. ### Acceptance - `madt_worktrees add` returns promptly once the git op completes. - If a post-add step is genuinely needed, it does not add many seconds, or it does not block the tool return.

hexajon referenced this issue

2026-09-04 17:46:28 +00:00

bug(status): status --json ignores the documented ~2s fetch bound on cold calls, blocking 25-120s+ #470

hexajon commented

2026-09-04 17:46:39 +00:00

Author

Owner

Probably the same root as #470 (status --json blocks 25-120s+ on cold calls).

There I saw madtea status --json block 25-120s+ on the first calls of a session, with no remoteStale/remoteWarning fallback, then run under 2s once warm, even 8 at a time. The ~120s signature and the same candidates listed here (an unexpected network or fetch step, a lock wait) point at one unbounded cold-network/credential path shared by worktrees add and status. If the fix bounds that path once, it likely closes both.

Probably the same root as #470 (`status --json` blocks 25-120s+ on cold calls). There I saw `madtea status --json` block 25-120s+ on the first calls of a session, with no `remoteStale`/`remoteWarning` fallback, then run under 2s once warm, even 8 at a time. The ~120s signature and the same candidates listed here (an unexpected network or fetch step, a lock wait) point at one unbounded cold-network/credential path shared by `worktrees add` and `status`. If the fix bounds that path once, it likely closes both.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#469

No description provided.

Rows
Columns