Generated backend and protobuf contracts

fn default() -> Self

Purpose: Provides the fallback value for account data when the backend does not include an accounts field. It treats missing accounts as an empty list rather than as an error.

Data flow: No outside data comes in. It creates a RawAccounts value containing an empty vector, so later parsing code can continue as if the server simply returned no accounts.

Call relations: This is used by deserialization when RawAccountsCheckResponse is built from JSON and the accounts field is absent. It supports AccountsCheckResponse::deserialize by giving that function a safe starting point.

Call graph: 2 external calls (List, new).

fn deserialize(deserializer: D) -> Result<Self, D::Error>

Purpose: Turns the backend's account-check JSON into the cleaner AccountsCheckResponse shape used by the client. It exists because the backend can send accounts in more than one format.

Data flow: It receives raw JSON through Serde, Rust's serialization and deserialization library. First it reads the JSON into RawAccountsCheckResponse. If accounts are already a list, it keeps them. If accounts are a map, it walks through account_ordering, looks up each account, pulls out the nested account information, and builds AccountEntry values. The result is one AccountsCheckResponse with accounts, ordering, and the default account id.

Call relations: Serde calls this custom deserializer whenever code asks to parse an AccountsCheckResponse. It hands off the first parsing step to RawAccountsCheckResponse::deserialize, then performs the normalization that ordinary generated parsing could not do.

Call graph: 1 external calls (deserialize).

fn text(&self) -> Option<&str>

Purpose: Extracts useful text from one piece of message content. It filters out non-text structured content and empty plain strings.

Data flow: It reads one ContentFragment. If the fragment is structured, it only returns text when its content_type says it is text and the text is not empty. If the fragment is a raw string, it returns it only when it is not just whitespace. The output is either a borrowed text slice or nothing.

Call relations: TurnItem::text_values and WorklogMessage::text_values rely on this method to avoid repeating the rules for what counts as real text. It is the small gatekeeper that keeps empty or non-text fragments out of user-facing output.

fn text_values(&self) -> Vec<String>

Purpose: Collects all meaningful text pieces from a single turn item. A turn item can contain several content fragments, so this gathers them into a simple list of strings.

Data flow: It reads the item's content list. For each ContentFragment, it asks ContentFragment::text whether there is usable text. It copies each usable piece into a String and returns the list.

Call relations: Turn::message_texts and Turn::user_prompt use this when they need the text inside message items. It delegates the fine-grained filtering to ContentFragment::text.

fn diff_text(&self) -> Option<String>

Purpose: Finds a code diff inside a turn item, if that item represents one. A diff is the patch-style text showing what changed in files.

Data flow: It reads the item's kind and diff-related fields. If the kind is output_diff, it returns the direct diff field when it is not empty. If the kind is pr, it looks inside output_diff.diff and returns that when present. If neither shape contains a real diff, it returns nothing.

Call relations: Turn::unified_diff calls this across output items to find the first available patch. This method hides the fact that the backend may store diff text in different places depending on item type.

fn unified_diff(&self) -> Option<String>

Purpose: Gets the first available unified diff from a turn's output items. A unified diff is the common patch format used by tools like git.

Data flow: It reads the turn's output_items in order. For each item, it asks TurnItem::diff_text whether that item contains a usable diff. It returns the first diff it finds, or nothing if none of the items contain one.

Call relations: CodeTaskDetailsResponse::unified_diff calls this on the current diff task turn and assistant turn. This method is the turn-level search step between the full task response and individual output items.

fn message_texts(&self) -> Vec<String>

Purpose: Collects assistant-facing text messages from a turn. It looks both at normal output message items and at assistant messages stored in the worklog.

Data flow: It starts with an empty list. It reads output_items, keeps only items whose kind is message, and adds their text values. Then, if there is a worklog, it scans each worklog message, keeps only messages written by the assistant, and adds their text values too. It returns the combined list of strings.

Call relations: CodeTaskDetailsResponse::assistant_text_messages calls this for the current diff task turn and assistant turn. Inside the worklog path, it uses WorklogMessage::is_assistant and WorklogMessage::text_values to decide what to include.

fn user_prompt(&self) -> Option<String>

Purpose: Extracts the user's prompt text from a turn. It joins multiple prompt parts with blank lines so the result reads like a single message.

Data flow: It reads input_items, keeps message items, and only includes items whose role is user or whose role is missing. It collects their text values. If there are no parts, it returns nothing. Otherwise, it joins the parts with two newline characters and returns the combined prompt.

Call relations: CodeTaskDetailsResponse::user_text_prompt calls this on the current user turn. It uses TurnItem::text_values to handle the content fragments inside each input item.

fn error_summary(&self) -> Option<String>

Purpose: Returns a readable error message for a turn if the turn has an error. It keeps callers from needing to inspect the error object directly.

Data flow: It looks at the turn's optional error field. If an error is present, it asks TurnError::summary to turn the code and message into one string. If there is no error, it returns nothing.

Call relations: CodeTaskDetailsResponse::assistant_error_message uses this on the current assistant turn. It is the bridge from task-level error lookup to TurnError's formatting rule.

fn is_assistant(&self) -> bool

Purpose: Checks whether a worklog message was written by the assistant. This matters because only assistant worklog text should be shown as assistant output.

Data flow: It reads the optional author and the author's optional role. If the role exists and equals assistant, ignoring letter case, it returns true. Missing author, missing role, or any other role returns false.

Call relations: Turn::message_texts uses this while scanning a worklog. It acts as the filter that separates assistant messages from other worklog entries.

fn text_values(&self) -> Vec<String>

Purpose: Collects meaningful text fragments from a worklog message. It safely returns an empty list when the message has no content.

Data flow: It reads the message's optional content. If content exists, it walks through content.parts and uses ContentFragment::text to keep only usable text, returning those pieces as strings. If content is missing, it returns an empty vector.

Call relations: Turn::message_texts calls this after WorklogMessage::is_assistant confirms the message came from the assistant. It reuses ContentFragment::text so worklog text follows the same filtering rules as normal message text.

fn summary(&self) -> Option<String>

Purpose: Turns an error code and error message into one readable string. It avoids showing awkward empty pieces when only one part is present.

Data flow: It reads the optional code and message, treating missing values as empty strings. If both are empty, it returns nothing. If only one is present, it returns that one. If both are present, it returns them as "code: message".

Call relations: Turn::error_summary calls this when a turn contains an error. It uses formatting to combine both fields in the common case where the backend provides both a machine-style code and a human-readable message.

Call graph: 1 external calls (format!).

fn unified_diff(&self) -> Option<String>

Purpose: Finds the most relevant code diff in a task-details response. It prefers the dedicated diff task turn, then falls back to the assistant turn.

Data flow: It looks at current_diff_task_turn first and current_assistant_turn second. For each present turn, it asks Turn::unified_diff for a patch. It returns the first patch found, or nothing if neither turn contains one.

Call relations: This is part of the CodeTaskDetailsResponseExt trait implementation, giving callers a simple task-level method instead of making them know where diffs may be stored. It hands the detailed search to Turn::unified_diff.

fn assistant_text_messages(&self) -> Vec<String>

Purpose: Collects assistant text messages from the task-details response. It gives the rest of the client a plain list of assistant-visible text, separate from diffs.

Data flow: It creates an empty list. It checks the current diff task turn and current assistant turn, skipping any that are missing. For each present turn, it appends the result of Turn::message_texts. The output is one combined vector of strings.

Call relations: This method is exposed through CodeTaskDetailsResponseExt for higher-level display code. It delegates per-turn extraction to Turn::message_texts, which in turn reads output items and assistant worklog messages.

Call graph: 1 external calls (new).

fn user_text_prompt(&self) -> Option<String>

Purpose: Returns the user's prompt from the current user turn, when one exists. It provides a simple way to show or reuse what the user asked.

Data flow: It reads current_user_turn. If there is a turn, it asks Turn::user_prompt to extract and join the prompt text. If the user turn is missing or has no prompt text, it returns nothing.

Call relations: This is the task-level entry point for prompt extraction in CodeTaskDetailsResponseExt. It hands the actual item filtering and joining to Turn::user_prompt.

fn assistant_error_message(&self) -> Option<String>

Purpose: Returns a readable assistant error message from the task response, if the assistant turn failed and reported one.

Data flow: It reads current_assistant_turn. If present, it asks Turn::error_summary for the turn's formatted error. If there is no assistant turn or no usable error, it returns nothing.

Call relations: This is the task-level error lookup method in CodeTaskDetailsResponseExt. It delegates the turn-specific part to Turn::error_summary, which delegates formatting to TurnError::summary.

fn deserialize_vec(deserializer: D) -> Result<Vec<T>, D::Error>

Purpose: Deserializes a vector field while treating a missing or null value as an empty list. This makes parsing tolerant of backend responses that omit arrays.

Data flow: It receives a Serde deserializer for a field that should be a Vec<T>. It first tries to read it as Option<Vec<T>>. If the value is present, it returns the vector. If it is missing or null, it returns an empty vector.

Call relations: Several fields in Turn, TurnItem, and Worklog use this helper through serde attributes. During JSON parsing, Serde calls it for those fields so the rest of the code can safely loop over vectors without checking for null.

Call graph: 1 external calls (deserialize).

fn fixture(name: &str) -> CodeTaskDetailsResponse

Purpose: Loads a named test fixture and parses it as CodeTaskDetailsResponse. It keeps the tests short by centralizing fixture lookup and JSON parsing.

Data flow: It receives a fixture name such as diff or error. It chooses the matching JSON file embedded at compile time, panics if the name is unknown, and parses the JSON into CodeTaskDetailsResponse. The parsed response is returned to the test.

Call relations: All the tests in this module call this helper before checking extraction behavior. It uses include_str! to read fixture files into the test binary and serde_json::from_str to parse them.

Call graph: 3 external calls (include_str!, panic!, from_str).

fn unified_diff_prefers_current_diff_task_turn()

Purpose: Checks that diff extraction finds the expected diff when the current diff task turn contains one. This protects the preference order used by CodeTaskDetailsResponse::unified_diff.

Data flow: It loads the diff fixture, calls unified_diff on the parsed details, and expects a diff to be present. It then asserts that the returned text contains a git-style diff marker.

Call relations: This test calls tests::fixture to get sample data and then exercises the public extension method. It indirectly covers CodeTaskDetailsResponse::unified_diff, Turn::unified_diff, and TurnItem::diff_text.

Call graph: 2 external calls (assert!, fixture).

fn unified_diff_falls_back_to_pr_output_diff()

Purpose: Checks that diff extraction can fall back to a pull-request-style output_diff payload. This matters because the backend may store patch text in more than one shape.

Data flow: It loads the error fixture, calls unified_diff, and expects a diff to be present. It asserts that the returned patch mentions lib.rs, proving the fallback path found the embedded diff.

Call relations: This test uses tests::fixture and then calls the task-level unified_diff method. It specifically protects the branch in TurnItem::diff_text that reads output_diff.diff from pr items.

Call graph: 2 external calls (assert!, fixture).

fn assistant_text_messages_extracts_text_content()

Purpose: Checks that assistant text extraction returns the expected text and ignores non-text or irrelevant content. It verifies the client can show a clean assistant message.

Data flow: It loads the diff fixture, calls assistant_text_messages, and compares the result with a one-item list containing "Assistant response".

Call relations: This test calls tests::fixture and the CodeTaskDetailsResponseExt assistant_text_messages method. It indirectly exercises Turn::message_texts, TurnItem::text_values, and ContentFragment::text.

Call graph: 2 external calls (assert_eq!, fixture).

fn user_text_prompt_joins_parts_with_spacing()

Purpose: Checks that multiple user prompt fragments are joined with a blank line between them. This keeps reconstructed prompts readable.

Data flow: It loads the diff fixture, calls user_text_prompt, and expects a prompt to be present. It then compares the result with two lines joined by two newline characters.

Call relations: This test uses tests::fixture and the task-level user_text_prompt method. It protects the joining behavior inside Turn::user_prompt.

Call graph: 2 external calls (assert_eq!, fixture).

fn assistant_error_message_combines_code_and_message()

Purpose: Checks that an assistant error with both a code and a message is displayed as one combined string. This protects the readable error format shown to users.

Data flow: It loads the error fixture, calls assistant_error_message, and expects an error string to be present. It compares that string with "APPLY_FAILED: Patch could not be applied".

Call relations: This test uses tests::fixture and the task-level assistant_error_message method. It indirectly checks Turn::error_summary and TurnError::summary.

Call graph: 2 external calls (assert_eq!, fixture).

fn new(limit_name: String, metered_feature: String) -> AdditionalRateLimitDetails

Purpose: Creates a new AdditionalRateLimitDetails value with the required fields filled in. It leaves the optional detailed rate-limit status unset, so callers can add it later only when they have that information.

Data flow: It takes a limit_name and a metered_feature as input. It puts those two strings into a new AdditionalRateLimitDetails struct and sets rate_limit to None, meaning no rate-limit detail field is included yet. The finished struct is returned to the caller.

Call relations: This is the convenience constructor for this generated model. Other code can call it when building an API response or request object, then optionally fill in rate_limit before the value is serialized to JSON or used elsewhere.

fn new(has_credits: bool, unlimited: bool) -> CreditStatusDetails

Purpose: Creates a new credit-status value with the two required facts: whether credits exist and whether access is unlimited. The extra fields start out absent, so callers can fill them in only when they have that information.

Data flow: It takes two boolean inputs: has_credits and unlimited. It places those values into a new CreditStatusDetails struct, sets balance, approx_local_messages, and approx_cloud_messages to None, and returns the completed struct to the caller.

Call relations: The call graph does not show a specific caller for this constructor. In normal use, code that needs to create a credit-status API object would call this first, then optionally add balance or message-count details before the value is serialized into JSON or passed deeper into the backend model layer.

fn new(
        used_percent: i32,
        limit_window_seconds: i32,
        reset_after_seconds: i32,
        reset_at: i32,
    ) -> RateLimitWindowSnapshot

Purpose: Creates a new RateLimitWindowSnapshot from four integer values. Code uses it when it already knows the rate-limit numbers and wants them packaged into the standard API model.

Data flow: The function receives four numbers: the percentage used, the window length in seconds, the seconds until reset, and the reset time. It places those values directly into a new RateLimitWindowSnapshot object and returns that object. It does not read outside state or change anything else.

Call relations: This constructor is the simple front door for building this model by hand. Other generated or application code can call it when preparing rate-limit data to pass around or serialize to JSON; the returned object can then be sent onward through the API serialization layer.

fn new(allowed: bool, limit_reached: bool) -> RateLimitStatusDetails

Purpose: Creates a new rate-limit status value with the two essential answers: whether the action is allowed and whether the limit has been reached. It starts with no primary or secondary window details attached.

Data flow: It receives two boolean values: allowed and limit_reached. It places those into a new RateLimitStatusDetails object, sets both optional window fields to absent, and returns the completed object to the caller.

Call relations: Code that needs to build a rate-limit status response can call this constructor first, then optionally fill in the primary_window or secondary_window fields later. This function does not call other project functions; it simply prepares the basic data object for later API serialization or internal use.

fn new(
        limit: String,
        used: String,
        remaining: String,
        used_percent: i32,
        remaining_percent: i32,
        reset_after_seconds: i32,
        reset_at: i32,

Purpose: Creates a new spend-control limit details record from the required pieces of information. It is a convenience constructor so callers do not have to fill every field by hand.

Data flow: The caller provides the limit, used amount, remaining amount, used and remaining percentages, and reset timing values. The function puts those values into a new SpendControlLimitDetails object, sets source to missing by default, and returns the completed object.

Call relations: This constructor is used when some other part of the program needs to build this API model before storing it, returning it, or turning it into JSON. It does not call other project functions; it simply packages the supplied values into the standard data shape expected by the API.

fn new(reached: bool) -> SpendControlStatusDetails

Purpose: Creates a new spend-control status object when the caller knows whether the limit has been reached. It starts with no individual limit details attached, leaving that optional information to be filled in later if needed.

Data flow: The caller gives in one value: reached, a true-or-false answer to whether the spend control was hit. The function puts that value into a new SpendControlStatusDetails object and sets individual_limit to None, meaning the individual limit field is not included yet. The result is a ready-to-use status object.

Call relations: This constructor is used when other parts of the code need to build this API model before sending it, storing it, or returning it. It does not call out to other functions; it simply creates the data structure in its default minimal form so later code can serialize it or add optional details.

fn new(plan_type: PlanType) -> RateLimitStatusPayload

Purpose: Creates a new rate-limit status payload with the required plan type filled in and all optional details left out. This is useful when code wants to start with the smallest valid response and add extra information only when it is available.

Data flow: It takes one input, plan_type, which says what subscription or workspace plan applies. It places that value into a new RateLimitStatusPayload and sets every optional field, such as credits and spending controls, to None, meaning they will be absent unless later filled in. The result is a ready-to-use payload object.

Call relations: This constructor is the simple starting point for building this API model. Other backend code can call it when preparing a rate-limit status response, then optionally attach more detailed limit, credit, or spending information before the payload is serialized into JSON for the client.

fn new(task: models::TaskResponse) -> CodeTaskDetailsResponse

Purpose: This creates a new code task details response from a required task. It starts with no current turn information, leaving those optional fields empty until another part of the program fills them in if needed.

Data flow: It receives a TaskResponse as input. It wraps that task in a Box, which means the task is stored indirectly on the heap rather than directly inside the struct, and then builds a CodeTaskDetailsResponse with all three optional turn fields set to None. The result is a ready-to-use response object containing the task and no extra turn data.

Call relations: This constructor is used when some other part of the API code needs to build a task-details response. Inside, it calls the standard Box::new-style constructor to wrap the task before returning the finished response object.

Call graph: 1 external calls (new).

fn new(
        number: i32,
        url: String,
        state: String,
        merged: bool,
        mergeable: bool,
    ) -> GitPullRequest

Purpose: Creates a new pull request record with the required fields filled in and all optional fields left empty. Someone would use this when they know the core pull request facts but may add extra details later.

Data flow: It receives the required pull request details: its number, URL, state, whether it has been merged, and whether it is mergeable. It places those values into a new GitPullRequest object, sets every optional field to None to mean “not provided,” and returns the completed object.

Call relations: The call graph does not show specific callers for this constructor. In the broader flow, code that needs to create a pull request model would call this first, then optionally fill in extra fields such as title, body, branch names, comments, or diff before the object is serialized to JSON or passed around inside the program.

fn new(
        id: String,
        assistant_turn_id: String,
        pull_request: models::GitPullRequest,
    ) -> ExternalPullRequestResponse

Purpose: Creates a new ExternalPullRequestResponse with the required fields filled in. It starts with no codex_updated_sha, because that value is optional and may not be known or relevant.

Data flow: It receives an response id, an assistant turn id, and a GitPullRequest object. It puts those values into a new response struct, wraps the pull request in a heap-owned box so the struct stores it indirectly, sets codex_updated_sha to missing, and returns the completed response object.

Call relations: This constructor is used when other code needs to build this API response in a safe, consistent way. During construction it hands the pull request value to Box::new, which is the standard Rust tool for placing a value behind a pointer-like container.

Call graph: 1 external calls (new).

fn new(
        id: String,
        title: String,
        has_generated_title: Option<bool>,
        archived: bool,
        has_unread_turn: bool,
    ) -> TaskListItem

Purpose: Creates a new TaskListItem with the required task-list fields filled in. It gives callers a safe starting point where optional details that are not yet known are left empty.

Data flow: The caller provides an id, a title, an optional has_generated_title flag, an archived flag, and a has_unread_turn flag. The function places those values into a new TaskListItem, sets updated_at, created_at, task_status_display, and pull_requests to None, and returns the completed struct to the caller.

Call relations: This constructor is used when code needs to build a task list item from known core details before sending it through the API model layer. It does not call other project functions; it simply assembles the data into the standard shape expected by the rest of the generated OpenAPI models.

fn new(items: Vec<models::TaskListItem>) -> PaginatedListTaskListItem

Purpose: Creates a new paginated task-list response from a list of task items. It starts with no cursor, which is useful when there is no next-page marker yet or the caller plans to fill it in later.

Data flow: It receives a vector, meaning an ordered list, of TaskListItem values. It puts that list into the items field, sets cursor to None, and returns a complete PaginatedListTaskListItem object ready to serialize to JSON or pass around in Rust.

Call relations: This constructor is the simple entry point for code that needs to build this response model. Generated API or backend code can call it when preparing a paginated task-list reply, then optionally set the cursor before the response is sent.

fn new(
        id: String,
        title: String,
        archived: bool,
        external_pull_requests: Vec<models::ExternalPullRequestResponse>,
    ) -> TaskResponse

Purpose: Creates a new TaskResponse with the required task information filled in and all optional information left empty. This gives callers a safe starting point when they only know the minimum fields needed for an API response.

Data flow: It receives a task id, a title, an archived flag, and a list of external pull request responses. It places those values into a new TaskResponse, sets optional fields like creation time, current turn id, unread status, and metadata to None, and returns the completed struct.

Call relations: This constructor is used when some other part of the backend needs to build a task response before sending or further filling it. It does not hand work off to other functions; it simply packages the given values into the API model in the expected format.

fn new() -> ConfigBundleResponse

Purpose: Creates an empty ConfigBundleResponse, with neither configuration file set. This is useful as a clean starting point before filling in whichever files the response should include.

Data flow: No information is passed in. The function builds a new response object where config_toml is absent and requirements_toml is absent. It returns that newly created object and does not change anything else.

Call relations: Code that needs to construct this API response can call this function first, then add the delivered config or requirements data if needed. It does not hand work off to other functions; it simply creates the default response shape expected by the generated model.

fn new(
        contents: Option<String>,
        sha256: Option<String>,
        updated_at: Option<String>,
        updated_by_user_id: Option<String>,
    ) -> ConfigFileResponse

Purpose: Creates a new ConfigFileResponse from the four possible pieces of configuration file information. Code uses it when it wants to build this API response in one clear step.

Data flow: It receives optional values for the file contents, the SHA-256 fingerprint, the update time, and the updater's user ID. It places those values into a new ConfigFileResponse object without changing them. The result is a ready-to-use response value that can later be serialized into JSON or inspected by Rust code.

Call relations: This constructor belongs to the generated model itself. Other parts of the backend or API client can call it when they need to create a response object, and the resulting value can then be handed to serialization code from serde to become JSON for the API boundary.

fn new(id: String, name: String, contents: String) -> DeliveredTomlFragment

Purpose: This creates a new DeliveredTomlFragment from an ID, a name, and the TOML text contents. It is a convenience constructor so callers can build the model in one clear step.

Data flow: The caller provides three strings: the fragment ID, the fragment name, and the fragment contents. The function places those strings into the matching fields of a new DeliveredTomlFragment value. It returns that completed value and does not change anything else.

Call relations: This constructor is used when some other part of the code needs to produce this API model before sending it onward or storing it in memory. It does not call other project functions; it simply packages the provided pieces of data into the agreed API shape.

fn new() -> DeliveredConfigToml

Purpose: Creates a blank DeliveredConfigToml value. Someone would use this when they need to start with an empty delivered configuration object and fill in fields later if needed.

Data flow: No input is required. The function builds a new DeliveredConfigToml where enterprise_managed is set to None, meaning the field is not present yet. It returns that new struct and does not change anything else.

Call relations: This constructor is the simple starting point for code that wants to create this API model by hand. After it returns the empty object, other code can set enterprise_managed before the value is serialized and sent, or leave it absent so it is omitted from the outgoing data.

fn new() -> DeliveredRequirementsToml

Purpose: Creates a fresh DeliveredRequirementsToml value with no enterprise_managed data set yet. Someone would use this when they want to build the API object step by step in Rust.

Data flow: Nothing is passed in. The function makes a new struct and sets enterprise_managed to None, meaning the field is absent for now. It returns that new empty model to the caller, which may later fill in the field or serialize it as part of an API response or request.

Call relations: This is the simple constructor for the model. Other code can call it whenever it needs a blank DeliveredRequirementsToml value; after that, Rust’s serialization and deserialization support can turn the value into API data or read API data back into the same shape.

fn as_str_name(&self) -> &'static str

Purpose: Returns the stable Protocol Buffers name for a wire API value. This is useful when code needs the exact text name used in the schema, for logging, storage, or matching with protocol-level data.

Data flow: It starts with a WireApi enum value, such as Unspecified or Responses. It matches that value to the official schema name and returns that name as text. It does not change any stored data.

Call relations: This helper belongs to the generated enum support code. Other code can call it whenever it needs to turn the numeric Rust enum value into the schema’s string label.

fn from_str_name(value: &str) -> ::core::option::Option<Self>

Purpose: Turns an official Protocol Buffers enum name back into a WireApi value. It lets code safely interpret text that uses the schema’s enum names.

Data flow: It receives a string. If the string is one of the known wire API names, it returns the matching enum value wrapped in Some; if the text is unknown, it returns None. Nothing else is changed.

Call relations: This is the reverse of WireApi::as_str_name. Code that reads protocol-style names can call it before storing or comparing the value as a Rust enum.

async fn connect(dst: D) -> Result<Self, tonic::transport::Error>

Purpose: Creates a ready-to-use client by opening a connection to a gRPC endpoint. A caller uses this when it has an address for the configuration loader service and wants to call it remotely.

Data flow: It receives a destination, such as a service URL or endpoint-like value. It turns that into a tonic endpoint, connects asynchronously, then wraps the connection in a ThreadConfigLoaderClient. The result is either a connected client or a transport error if the connection cannot be made.

Call relations: This is the convenient starting point for client-side code. After connecting, it hands the live connection to ThreadConfigLoaderClient::new, which builds the actual client wrapper used for later load calls.

Call graph: 2 external calls (new, new).

fn new(inner: T) -> Self

Purpose: Wraps an existing gRPC transport in a thread configuration loader client. This is used when the caller already has a channel or service object and just needs the generated client interface around it.

Data flow: It receives an inner transport object. It wraps that object in tonic’s gRPC client machinery and returns a ThreadConfigLoaderClient containing it. The original transport becomes owned by the new client.

Call relations: This is used by connect after a network connection is opened, and also by generated setup helpers such as with_interceptor. It is the basic constructor for the client side of this service.

Call graph: 1 external calls (new).

fn with_origin(inner: T, origin: Uri) -> Self

Purpose: Creates a client that sends requests with a specific origin URI. This is useful in advanced routing setups where the transport connection and the logical service origin need to be distinguished.

Data flow: It receives an inner transport and an origin URI. It builds tonic’s gRPC client wrapper using that origin and returns a ThreadConfigLoaderClient. The returned client will use that origin when making service calls.

Call relations: This is another client construction path. It delegates the origin-aware wrapping to tonic’s generated support code, then returns the same kind of client used by load.

Call graph: 1 external calls (with_origin).

fn with_interceptor(
            inner: T,
            interceptor: F,
        ) -> ThreadConfigLoaderClient<InterceptedService<T, F>>

Purpose: Creates a client that runs an interceptor around each request. An interceptor is a small hook that can inspect or modify outgoing calls, often to add authentication or tracing information.

Data flow: It receives a transport and an interceptor function or object. It combines them into an intercepted service, then wraps that service in a new ThreadConfigLoaderClient. The output is a client whose future requests pass through the interceptor first.

Call relations: This sits in the client setup path before any actual load request is sent. It uses the same underlying new construction pattern, but inserts the extra request hook in front of the transport.

Call graph: 2 external calls (new, new).

fn send_compressed(mut self, encoding: CompressionEncoding) -> Self

Purpose: Configures the client to compress outgoing requests using a chosen compression format. Compression can reduce network size, but the server must support the same format.

Data flow: It receives the client and a compression encoding. It updates the inner gRPC client so future requests are sent compressed, then returns the updated client for chaining. It does not send a request by itself.

Call relations: This is a client configuration step used before calling load. It hands the compression choice to tonic’s client machinery, which applies it when a request is later sent.

Call graph: 1 external calls (send_compressed).

fn accept_compressed(mut self, encoding: CompressionEncoding) -> Self

Purpose: Configures the client to accept compressed responses from the server. This tells the client which compressed response format it knows how to decode.

Data flow: It receives the client and a compression encoding. It updates the inner gRPC client so later responses using that encoding can be decompressed, then returns the updated client. No network call happens here.

Call relations: This is usually called during client setup. When load later receives a response, tonic uses this setting to decode compressed response bodies if needed.

Call graph: 1 external calls (accept_compressed).

fn max_decoding_message_size(mut self, limit: usize) -> Self

Purpose: Sets the largest response message the client is willing to decode. This protects the client from unexpectedly huge messages.

Data flow: It receives the client and a byte-size limit. It stores that limit in the inner gRPC client and returns the updated client. Future responses larger than the limit may be rejected by tonic.

Call relations: This is part of client setup before request sending. The limit is enforced later by tonic when load receives and decodes a response.

Call graph: 1 external calls (max_decoding_message_size).

fn max_encoding_message_size(mut self, limit: usize) -> Self

Purpose: Sets the largest request message the client is willing to encode and send. This helps prevent accidental oversized outbound requests.

Data flow: It receives the client and a byte-size limit. It records that limit inside the inner gRPC client and returns the updated client. Future outgoing requests are checked against this setting.

Call relations: This prepares the client before calling load. Tonic uses the stored limit when it serializes the request into bytes for the gRPC call.

Call graph: 1 external calls (max_encoding_message_size).

async fn load(
            &mut self,
            request: impl tonic::IntoRequest<super::LoadThreadConfigRequest>,
        ) -> std::result::Result<tonic::Response<super::LoadThreadConfigResponse>, t

Purpose: Sends a LoadThreadConfigRequest to the thread configuration loader service and waits for a LoadThreadConfigResponse. This is the generated client method for the service’s main operation.

Data flow: It receives a request-like value containing fields such as thread id and current working directory. It first waits until the inner gRPC service is ready, converts the input into a proper gRPC request, attaches method metadata, and sends a unary call, meaning one request produces one response. It returns either the response from the server or a gRPC status error.

Call relations: This is the client-side endpoint that application code calls when it wants thread configuration. It uses tonic’s readiness check, Protocol Buffers codec, fixed service path, and unary-call machinery to hand the request over to the remote server method named Load.

Call graph: 6 external calls (ready, unary, new, into_request, from_static, default).

fn new(inner: T) -> Self

Purpose: Builds a server wrapper around application code that implements the thread configuration loading behavior. The wrapper is what tonic can register as a gRPC service.

Data flow: It receives an implementation object for the ThreadConfigLoader trait. It places that object in shared ownership storage and builds a ThreadConfigLoaderServer around it. The result is a service object ready for further configuration or registration.

Call relations: This is the common server setup entry point. It immediately delegates to from_arc, which does the actual field setup using a shared pointer so requests can safely refer to the same implementation.

Call graph: 2 external calls (new, from_arc).

fn from_arc(inner: Arc<T>) -> Self

Purpose: Builds a server wrapper around an already shared implementation object. This is useful when the application already keeps the loader in an Arc, which is Rust’s thread-safe shared pointer.

Data flow: It receives a shared pointer to the real loader implementation. It stores that pointer and initializes compression and message-size settings to their defaults. It returns a configured server wrapper with no custom limits or compression enabled yet.

Call relations: This is called by new, and can also be used directly by server setup code. Later, call uses the stored shared implementation to dispatch incoming gRPC requests to the real load method.

Call graph: 1 external calls (default).

fn with_interceptor(inner: T, interceptor: F) -> InterceptedService<Self, F>

Purpose: Creates a server service that runs an interceptor around incoming requests. This hook can check or decorate requests before they reach the actual loader, for example for authentication or logging.

Data flow: It receives the loader implementation and an interceptor. It first builds a normal server wrapper, then combines it with the interceptor and returns the intercepted service. Incoming requests will pass through that interceptor before normal service handling.

Call relations: This is used during server setup instead of plain new when request filtering or metadata handling is needed. It wraps the generated server before tonic starts routing calls to call.

Call graph: 2 external calls (new, new).

fn accept_compressed(mut self, encoding: CompressionEncoding) -> Self

Purpose: Configures the server to accept compressed requests in a chosen format. This lets clients reduce request size when both sides support the same compression.

Data flow: It receives the server wrapper and a compression encoding. It marks that encoding as allowed for incoming requests, then returns the updated server. No request is processed at this point.

Call relations: This is a server setup step. When call later receives a matching request, the generated gRPC machinery uses this setting while decoding the request body.

Call graph: 1 external calls (enable).

fn send_compressed(mut self, encoding: CompressionEncoding) -> Self

Purpose: Configures the server to compress responses using a chosen format when the client supports it. This can make responses smaller over the wire.

Data flow: It receives the server wrapper and a compression encoding. It marks that encoding as available for outgoing responses and returns the updated server. The effect is applied later during request handling.

Call relations: This is called during server setup. The call function later copies this setting into tonic’s per-request gRPC handler so responses can be compressed when appropriate.

Call graph: 1 external calls (enable).

fn max_decoding_message_size(mut self, limit: usize) -> Self

Purpose: Sets the largest incoming request message the server will decode. This protects the service from unexpectedly large or abusive requests.

Data flow: It receives the server wrapper and a byte-size limit. It stores that limit in the server configuration and returns the updated server. Future incoming requests are checked against this size during decoding.

Call relations: This is configured before the service starts receiving calls. When call builds the gRPC handler for a request, it passes this limit into tonic’s message-size configuration.

fn max_encoding_message_size(mut self, limit: usize) -> Self

Purpose: Sets the largest response message the server will encode and send. This helps avoid sending unexpectedly huge responses.

Data flow: It receives the server wrapper and a byte-size limit. It stores that limit in the server configuration and returns the updated server. Later responses larger than the limit may be rejected by tonic.

Call relations: This is a server setup option. During call, the stored limit is applied to the gRPC handler that serializes the response.

fn poll_ready(
            &mut self,
            _cx: &mut Context<'_>,
        ) -> Poll<std::result::Result<(), Self::Error>>

Purpose: Reports whether the generated server is ready to receive a request. In this generated implementation, it always says it is ready.

Data flow: It receives a mutable reference to the server and a task context, but does not need to inspect either in this implementation. It immediately returns a ready success value. It changes no server state.

Call relations: The HTTP/gRPC runtime calls this before sending a request into call. Because this server wrapper has no internal back-pressure here, it simply tells the runtime to continue.

Call graph: 1 external calls (Ready).

fn call(&mut self, req: http::Request<B>) -> Self::Future

Purpose: Routes an incoming HTTP/gRPC request to the correct generated service method. For this service, it recognizes the Load path and forwards the decoded request to the real loader implementation.

Data flow: It receives an HTTP request. It checks the request path: if it is the thread configuration Load path, it builds a small adapter service, applies compression and message-size settings, decodes the request with the Protocol Buffers codec, calls the implementation’s load method, and returns the gRPC response. If the path is unknown, it returns a gRPC “unimplemented” response.

Call relations: This is the main server-side request dispatch point. The runtime calls it after poll_ready; for valid Load calls it hands work to the application’s implementation of the ThreadConfigLoader trait, while tonic handles the byte-level encoding and response wrapping.

Call graph: 6 external calls (pin, uri, new, default, new, default).

fn clone(&self) -> Self

Purpose: Creates another server wrapper pointing at the same underlying loader implementation and using the same settings. This lets the gRPC runtime duplicate the service handle safely when needed.

Data flow: It reads the existing server’s shared implementation pointer and configuration fields. It clones the shared pointer and copies the compression and size settings into a new server wrapper. The original and cloned wrappers both refer to the same real loader.

Call relations: This supports tonic’s service infrastructure, which may clone services as it builds routing or serves requests. The clone preserves the behavior configured by new, from_arc, and the compression or message-size setup methods.