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

New issue

Open

opened 2026-09-04 17:46:28 +00:00 by hexajon · 0 comments

hexajon commented

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

Owner

madtea status --json's documented ~2s fetch bound does not hold on the first status calls of a session. Those calls block for 25s to 120s+ and return nothing, instead of returning within ~2s or falling back to cached refs. Once the session is warm, every call is fast.

Documented contract

The tool description and status --help promise: each call wraps a real git fetch (origin) bounded by a short ~2s timeout; on timeout or failure it falls back to the last-fetched refs with remoteStale/remoteWarning; status "never blocks on, or fails because of, the network."

What I saw

I swept madtea status --json across about 120 local clones to get fresh ahead/behind counts.

COLD (first calls of the session):
- Single calls blocked past a hard 25s timeout, and once past 120s. No JSON returned, and no remoteStale/remoteWarning fallback fired, just a block until I killed it.
- Run 8 at a time across the clones with a 15s hard timeout each, 56 of 124 calls exceeded 15s and were killed.
WARM (same session, right after):
- The same clones, again 8 at a time, all 124 returned in under 2s (slowest 1991ms), zero failures. Sequentially also all 1-2s.

So the contract holds warm and breaks cold. The ~2s bound and the stale fallback are not applied on the first-call path.

Read (hypothesis)

The cold cost looks like a one-time network or credential warmup that sits outside the ~2s fetch timeout, for example the first git-fetch credential resolution, or a forge connect/init step. On the cold path the call blocks on the OS default connect timeout (~120s) rather than the documented ~2s. The ~120s figure and the "unexpected network or fetch step / lock wait" candidates match #469 (madt_worktrees add blocks ~120s), so these are probably the same unbounded cold-network path in two commands.

Repro

Start from a cold credential/network state (e.g. the first status calls of a session).
Run madtea status --json in a repo and time it.
The first call(s) block well past 2s (I saw 25-120s+); later calls are ~1-2s. Neither the ~2s bound nor the remoteStale/remoteWarning fallback fires on the cold call.

Acceptance

The first madtea status call of a session returns within the documented bound, or falls back to cached refs with remoteStale/remoteWarning. It never blocks past ~2s on the network.
Any one-time warmup is bounded by the same timeout, or moved off the status hot path.
Cross-check #469: if it shares the root, fix both.

`madtea status --json`'s documented ~2s fetch bound does not hold on the first status calls of a session. Those calls block for 25s to 120s+ and return nothing, instead of returning within ~2s or falling back to cached refs. Once the session is warm, every call is fast. ### Documented contract The tool description and `status --help` promise: each call wraps a real `git fetch` (origin) bounded by a short ~2s timeout; on timeout or failure it falls back to the last-fetched refs with `remoteStale`/`remoteWarning`; status "never blocks on, or fails because of, the network." ### What I saw I swept `madtea status --json` across about 120 local clones to get fresh ahead/behind counts. - COLD (first calls of the session): - Single calls blocked past a hard 25s timeout, and once past 120s. No JSON returned, and no `remoteStale`/`remoteWarning` fallback fired, just a block until I killed it. - Run 8 at a time across the clones with a 15s hard timeout each, 56 of 124 calls exceeded 15s and were killed. - WARM (same session, right after): - The same clones, again 8 at a time, all 124 returned in under 2s (slowest 1991ms), zero failures. Sequentially also all 1-2s. So the contract holds warm and breaks cold. The ~2s bound and the stale fallback are not applied on the first-call path. ### Read (hypothesis) The cold cost looks like a one-time network or credential warmup that sits outside the ~2s fetch timeout, for example the first git-fetch credential resolution, or a forge connect/init step. On the cold path the call blocks on the OS default connect timeout (~120s) rather than the documented ~2s. The ~120s figure and the "unexpected network or fetch step / lock wait" candidates match #469 (`madt_worktrees add` blocks ~120s), so these are probably the same unbounded cold-network path in two commands. ### Repro 1. Start from a cold credential/network state (e.g. the first status calls of a session). 2. Run `madtea status --json` in a repo and time it. 3. The first call(s) block well past 2s (I saw 25-120s+); later calls are ~1-2s. Neither the ~2s bound nor the `remoteStale`/`remoteWarning` fallback fires on the cold call. ### Acceptance - The first `madtea status` call of a session returns within the documented bound, or falls back to cached refs with `remoteStale`/`remoteWarning`. It never blocks past ~2s on the network. - Any one-time warmup is bounded by the same timeout, or moved off the status hot path. - Cross-check #469: if it shares the root, fix both.

hexajon referenced this issue

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

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

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#470

No description provided.

Rows
Columns