Make the number of parallel code-host requests configurable (git config stack.codeHostConcurrency)

[OmerGronich]

What I'd like

A way to control how many requests stack makes to the code host at the same time, set through git config like the other options — for example:

git config stack.codeHostConcurrency 2

Why

Right now stack fires several code-host requests in parallel (it looks like 4 at a time). In my setup, that burst of simultaneous requests is too much and the calls start timing out, so stack fails partway through.

If I could set the number myself, I could find the sweet spot that works for me — maybe 3 or 2 is enough, and 1 as a worst case. Being able to tune it means stack finishes reliably instead of failing on the burst.

How I imagine it working

The number already exists in the code (codeHostConcurrency, default 4) but isn't exposed. It could be read from git config the same way stack.trunks and stack.blockLink already are:

git config stack.codeHostConcurrency 2     # two requests at a time
git config stack.codeHostConcurrency 1     # one at a time
git config stack.codeHostConcurrency 4     # current default

If it's not set, keep the current default of 4 so nothing changes for existing users.

[kitlangton]

I opened #49 with bounded retries for transient reads, fewer redundant GitLab detail requests, and a subprocess pipe-deadlock fix. Writes are never automatically retried because the host may already have accepted them. This is an automatic-recovery-first proposal, not the configurable concurrency setting requested here; the default stays at four.

Could you share whether this is GitHub or GitLab, your stack and gh/glab versions, the stack command, and the exact timeout output? Please redact tokens and private host/repository details. I have reproduced the failure-handling cases in tests, but not your environment, so I am leaving this open until we can check whether the proposed recovery is sufficient or a lower concurrency limit is still needed.

[kitlangton]

The automatic-recovery changes from #49 are now published in @kitlangton/stack@0.4.5 as latest. Could you update with npm install -g @kitlangton/stack@0.4.5 and retry the command that timed out? Please let me know whether it completes reliably, or share the redacted timeout output and CLI versions if it still fails. Leaving this open while we verify whether a separate concurrency setting is needed.