Module bounded_push 

The auto-push’s real git push with a deadline and its low-speed abort. What: Run the auto-push’s real git push (and its fetch and Git LFS upload) until it ends, or stops showing any sign of work with no connection to a remote open. Why: A push that shows nothing and holds no connection would otherwise hold the service’s push of that branch forever, and every later push of the repository would wait behind it. Such a push is stopped when its stall window passes, the commit stays saved locally, and the failure is reported like any other failed push. A push whose connection to the remote is open is never stopped for time (owner, 2026-11-03: “Wait while connected (Recommended)”; pick 5 of doc/planning/cli-git-shipped-limits-audit.md, the coordinator’s under the owner’s delegation and open to the owner’s veto): it has no ceiling, and the wrapper sets no low-speed abort for it.

In TS you’d write (pseudocode):

const { exitCode, output } = await nanoSpawn(gitPath, pushArgs, { cwd, signal: AbortSignal.timeout(deadlineMs) });

Structs

StopReport

What a stop reports: the limit that was hit, what the push had moved and how long it had run.

Enums

Patience

What: How long a bounded child may take: a fixed time, or a time without any sign of work and without an open connection. Why: A slow push that keeps moving data is working and should finish, and one whose connection to a remote is open is waiting for the remote and should wait too; one that shows nothing and holds no connection is stuck and should stop fast. A query has no transfer to measure and keeps a fixed bound.

StopCause

Why a push or query was stopped.

Constants

DEFAULT_PUSH_DEADLINE

How long a push with no connection to a remote open may go without any sign of work (the stall window) when the variable is absent or unusable. Where no progress can be measured, it is how long the push may run in all. Citation: no measurement or owner decision determines 30 seconds. The owner decided the rule, “Stop only on no progress (Recommended)”, and not the number. The journal of the commit service (read-only, 794 pushes that landed since 2026-10-20) holds whole-push times, p50 3.5 s, p99 26.4 s, maximum 72.4 s, which include connected time and so are not a measure of silence without a connection; no silence of a disconnected push is logged anywhere. The number is an open question for the owner (doc/planning/cli-git-shipped-limits-audit.md, “Push stall window, 30 seconds”).

MAX_PUSH_OUTPUT

The most output bytes kept from one push; a push that writes more is stopped. Citation: none yet. The owner decided “Keep all lines” for push output, which this cap limits, and no measurement of the size of a push’s output is logged; the audit lists it as a memory bound to be measured.

PUSH_DEADLINE_VARIABLE

Environment variable that sets the push deadline in whole seconds.

PUSH_QUEUED_LINE

What a person is told when a push is ended for showing no progress: the owner’s answer of 2026-11-03, “Bound it, keep retrying (Recommended)”, is that the service’s retry plan keeps the push and tries it again, and the line says so.

STOPPED_EXIT_CODE

Exit code recorded for a push that this wrapper stopped, the convention of timeout(1).

STOP_GRACE

How long a stopped push gets to end after the polite stop signal before it is killed. Citation: partial. The helpers of a stopped push were measured on 2026-11-03 to outlive it for 60 seconds, and a git-lfs that never answers for good, and empty tracking-ref locks appeared about 37 seconds after a stop; those justify the kill that follows the grace and the sweep, not five seconds, and no measurement of how long Git takes to remove its own locks on a polite stop exists. An open question for the owner.

WAIT_NOTE_PHRASE

What the line a push’s output gains has after the name of the program, when it waited with its connection open.

Functions

command_label

What: The name a run goes by in the lines about it: the program’s file name and its first word that is not an option, as in git push, git fetch or git-lfs push. Why: The wait line must say which of the wrapper’s network runs is waiting, and the command is the only thing that knows. The values of Git’s -c and -C options are skipped with them.

positive_seconds

What: Read a positive whole number of seconds from one environment value. Why: A zero, negative, fractional, empty or non-text value is no setting at all, never “no limit”, so a typo cannot remove a bound.

push_deadline

What: The push deadline: the environment’s value, or the default. Why: A person may need a longer deadline on a slow link or a shorter one on a flaky one.

push_patience

The patience of a push from the environment: the stall window.

run_bounded_push

What: Run a push command to its end or its deadline and capture its interleaved output, after the reference locks that a killed Git left in its repository have been cleared when their holder is proven gone. Why: Every start of the wrapper’s own fetch and push, the repetitions of a push included, goes through here (push_lock_clearing.rs).

run_bounded_push_once

What: Run a push command to its end or its deadline and capture its interleaved output. Why: Both streams share one anonymous file so lines keep the order Git wrote them, and a file needs no reader thread that a stuck helper could keep alive. A stopped push becomes a failed attempt that says so, so the commit stays saved and the failure is recorded for later invocations.

settle_locks

What: Remove the locks of a stopped tree now when it has ended, or on a thread of its own when it has not. Why: A killed process ends only when the kernel has run it once more, which a loaded or stalled host may not do within the grace; a sweep before that finds the tree running and removes nothing, and nothing would try again. The thread waits for the whole tree and then sweeps. Returns the thread, if one was started.

stop_push

What: Stop a running push: ask politely, wait the grace, then kill and collect it, and judge the reference locks it may have left. Why: Git’s own signal handling ends the helpers it started and removes its lock files, and a push that ignores the request cannot outlive the kill. A killed push leaves its lock files, which fail every later Git command on the same refs, so once the push and what it started are gone the locks they hold are swept.

strip_one_line_break

Remove exactly one trailing \n or \r\n, as the captured output of the incumbent does.

sweep_after_exit

What: Collect a killed child that the kernel has not released, and sweep the locks it leaves, on a thread of its own. Why: A killed process in an uninterruptible call (a stalled disk or file system) ends only when the kernel lets it go, and on its way out it can create a lock file that nothing will remove (measured on 2026-11-03: empty tracking-ref locks born about 37 seconds after the stop). The push is reported at its deadline and does not wait for that, so the child is collected here, and its locks are swept when it is gone. The thread holds no lock and ends with the child.

wait_until_done

What: Look at a running read-only query until it ends, stalls or floods its output, and say how quiet it got. Why: std has no timed wait, so the parent looks with try_wait, which never blocks; the clock reads the signs of work a few times a second. A query that works is waited for however long it takes: it has no wall-clock bound (owner, 2026-11-03: “Stop only on no progress”; the coordinator’s scope addition to picks 4 and 9 of doc/planning/cli-git-shipped-limits-audit.md, open to the owner’s veto), and on a system that counts nothing it is never judged stalled. quiet receives the longest quiet gap seen, for the ledger, and nothing where the system counts nothing.

wait_until_done_noting

What: The same wait as wait_until_done for a push, handing over the wait of a push that is waiting for its remote with the connection open. Why: The push is not stopped while it waits; the caller says so once, in a line, and the wait ends the way any other does.