Skip to main content

Module service_client

Module service_client 

Source
Expand description

The wrapper’s side of a commit through the commit service. What: The wrapper’s side of a commit through the resident service: connect, wait honestly while the operating system starts the service, send the request, show the queue position, survive a service that dies mid-request, and turn every failure into the plain text of service_messages.rs. Why: A failure the system can resolve is resolved here without the user: a service that is starting is waited for, one that crashed is reconnected to with the same request identity, one that was started from another release of the wrapper (older or newer, found by the release its welcome names) is asked to retire and is reached again once the manager has started the current one. Only what cannot be resolved ends the command.

In TS you’d write (pseudocode):

const result = await submit(config, request, stderr); // landed, or prepare again, or a ClientFailure

Structs§

ClientConfig
What the client needs to reach the service.
ScratchWatch
A scratch directory handed to the service: the service removes it when this value is dropped, and when the process that holds it dies by any means, because the connection is the only thing that says the directory is still wanted.

Enums§

Activation
What the client may rely on the operating system to do.
Submitted
What a request came to.

Constants§

COMMIT_WAIT
How long a commit waits in the queue before the client gives up and says so.
RECONNECTS
How many times a request is sent again after the connection broke before the client says it cannot be sure.
START_NOTICE_GRACE
How long a start takes before the client says it is starting the service.
START_WAIT
How long the client waits for the operating system to start the service.

Functions§

ask_to_retire
What: Asks the service listening at socket to finish its batch and exit, when one answers; nothing else is waited for. Why: The single service of the earlier releases is replaced by one service per worktree. It is asked politely first, in the protocol version it announced, so that a batch it is landing is finished; the manager then stops its units. A socket nobody listens on, or a service that does not greet, is no one to ask.
failure_for
The user-facing failure for a code the service gave.
submit
What: Sends a commit request and waits until it is answered. Why: The same identity goes with every send, so a service that landed the commit and died before answering reports it as already landed, and nothing lands twice.
wake
What: Tells the service that work items were written for a repository, starting it through the operating system when it is not running, and returns once the service has taken the message. Why: The wrapper never starts the service or runs the work itself; the message is the only thing the service needs to look at the repository’s work directory. The connection closes when the service has read the line, which is the confirmation that it will act.
watch_scratch
What: Hands the commit’s scratch directory to the service, which removes it when the connection closes. Why: A client killed without warning cannot remove what it made, and no one can tell afterwards whether it is gone or stopped: the open connection is the signal, without a process id and without a lock. The announcement is written at once and the greeting is not waited for, so a service that is frozen or still starting takes it when it reads, and a client killed meanwhile still loses its directory. A service that is not running takes nothing, and a service of another release refuses a message it does not know and closes nothing of the client’s; in both the client removes the directory itself when it ends, as it always has.