Module service_timing 

The lines the commit service writes about its life and about the time each request took. What: The lines the resident commit service writes to its log (standard error, which the service manager keeps in the journal) about its own life and about the time each request took: when it started, one line for each request it answered with the phases of the wait, a retire request, and its exit with the reason and the uptime. Why: After a slow commit the journal held ready and nothing else, so nothing said whether the time went to the queue, to another program’s hold on the index, to the landing or to a service being replaced. These lines cost one clock read per phase edge and one line per request; they name no person (the commit’s message and identities never appear) and are not shown to the person at the terminal.

In TS you’d write (pseudocode):

console.error(`cli-git-service: answered request=${id} queued_ms=${queued} lock_wait_ms=${lockWait} total_ms=${total}`);

Structs

Answered

Everything the line for one answered request states.

Arrival

When a connection was accepted and how long its request line took to arrive.

LandTiming

What: The phases of one landing the service itself spent time in, summed over the attempts a moving branch made it repeat. Why: The wait for another program’s hold on the index, the objects, the journal write, the branch move and the index update are the stretches a slow landing can lose time in; whatever else a landing did is reported as the reads that remain.

Enums

ExitReason

Why a service ended.

Constants

LOG_PREFIX

The prefix of every line the service writes, which journalctl shows after the unit name.

SLOW_LOCK_STEP

The wait for the index lock that is written down even when no holder was met: a flush of the marker or a wait that long is a slow landing’s first suspect. Exempt from a citation under LQM (class: notice pacing): it times a line the person reads or a log threshold, and nothing waits on it beyond the wait that already exists. Classed once in doc/planning/cli-git-shipped-limits- audit.md, “Exempt limits”; the coordinator’s pick under the owner’s delegation, open to the owner’s veto.

Functions

answered_line

What: One answered request as a line of key=value words, without the prefix. Why: Text values are written in Rust’s quoted form, which has no raw newline or unescaped quote, so the line stays one line whatever a client sent; the numbers are whole milliseconds.

exit_line

The line for the service’s own exit, with the time it ran since it began serving.

in_service

What: Whether this process is the resident service, which names its release once at the start (set_context). Why: Code both programs run (the auto-push’s fetch, the shadow’s init) records Git’s words in the service’s log in the service and as a client entry in the wrapper; a control that captures the service’s entries counts as the service.

index_update_ms_of

What: The duration, in whole milliseconds, that an answered line gives for removing the conclusion state and building and installing the new index. Why: The step was first logged as sync_ms, which reads as a disk sync although it is the follow-up of the landing that holds the index lock; it is index_update_ms now. Lines already in the journal keep the old key, so a reader asks for the new key and falls back to the old one.

lock_notes_fields

The words for what the wait for the lock found, empty when the lock was free at the first placement: the placements that found it held, the time spent flushing the marker and the time spent waiting, and the first and the last description of the held lock.

log

What: Writes one line to the service’s log. Why: Standard error is the service manager’s journal; one write carries the prefix, the line, its own time and the newline together, and a closed or broken stream is not the service’s failure.

log_entry

What: Writes one entry of a priority, with fields a reader can filter the journal on, and gives where it went. Why: The userinfo of every URL is masked (a push or a review reports what Git and a server said), the line on standard error is one line, then it states its own time (stamped_line); a native entry also carries the time as CLI_GIT_AT_MS, the priority and the context. Nothing here waits: see journald_native.

retire_line

The line for a retire message: a client of another release found this service and asked it to finish its batch and exit.

set_context

Names the release and instance every later entry carries as CLI_GIT_RELEASE and CLI_GIT_INSTANCE; the first call wins.

sink

The sink of this process.

stamped_line

What: The text of one log line: the prefix, the line, the time of the event as at_ms=<epoch milliseconds> at the end, and the newline. Why: The journal stamps a line when it receives it, and under load that can be seconds after the event; the line states its own time, at the end so that the prefix and the first word stay where readers look for them.

started_line

The line a service writes as it starts, before ready: the release it announces, the protocol, its process and the worktree instance it serves.

wait_line

What: The line for the end of a wait for the index lock, or nothing when the lock was free at the first placement and the acquisition was quick. Why: Written when the wait ends, not with the answer, so a landing that fails afterwards still leaves what it waited for. It says the total, how it split between flushing the marker and waiting for a holder, how many times the lock was found held, and what the first and the last look found (lock_found, lock_last).

wall_millis

The wall clock in whole milliseconds since the Unix epoch, the time a log line states for its own event.