clippy result_large_err fails Rust (capture layer) on every PR, including docs-only ones

[azlekov]

What is wrong

Rust (capture layer) fails on clippy in cli/dirad:

error: the `Err`-variant returned from this function is very large
   --> cli/dirad/src/...:386
386 | ) -> Result<(String, Option<bool>, ZavetConfig, Option<PathBuf>), Response> {
    |      ^^^^ the `Err`-variant is at least 160 bytes
    = help: try reducing the size of `dira_core::protocol::Response`, for example by
      boxing large elements or replacing it with `Box<dira_core::protocol::Response>`
    = note: `-D clippy::result-large-err` implied by `-D warnings`
error: could not compile `dirad` (lib) due to 1 previous error
error: could not compile `dirad` (lib test) due to 1 previous error

The job denies warnings (-D warnings), so this one lint fails the build outright, including the lib-test target.

Why it is showing up now

Nothing in the crate changed. clippy::result_large_err tightened, so a Response that was always this size now trips the threshold. It reproduces on a branch that touches only markdown, which is how it was found: #129 changes 43 .md files and zero .rs files and is red on this job.

The fix is a judgement call

Two options, and they are not equivalent:

1. Box it. Return Result<T, Box<Response>> at the call sites clippy names. Correct if Response genuinely is a large error payload and the Err path is rare. Costs an allocation on the error path and touches every caller that matches on it.
2. Shrink Response. If the size comes from one fat variant, box that variant instead. Better long term, wider blast radius.

An #[allow(clippy::result_large_err)] is the third option and the worst one, since it hides the size rather than deciding about it.

Blast radius

Until this is fixed, Rust (capture layer) is red on every PR, including documentation-only ones, so the job cannot signal anything about the change under review.

🤖 Generated with Claude Code

[azlekov]

Pinned down the exact site and scope.

Location: cli/dirad/src/zavet.rs:386, the private async fn query_repo:

async fn query_repo(
    state: &AppState,
    repo: Option<String>,
    cwd: Option<String>,
) -> Result<(String, Option<bool>, ZavetConfig, Option<PathBuf>), Response> {

Response is at least 160 bytes, and -D warnings turns the lint into a build failure. It kills both dirad (lib) and dirad (lib test), which is why Rust (capture layer) and Rust (windows) both fail on the identical error, not two separate problems.

Scope is smaller than I first assumed. query_repo is private to zavet.rs and has exactly six callers, all in that same file:

zavet.rs:668  zavet.rs:700  zavet.rs:753
zavet.rs:809  zavet.rs:1340 zavet.rs:1371

Every one is a match query_repo(state, repo, cwd).await. So Result<..., Box<Response>> is a one-file change: the signature, the Err(...) constructions inside the function, and a deref at those six match arms. No public API moves.

Worth deciding whether Response itself should shrink instead. If one variant carries the weight, boxing that variant fixes this everywhere rather than at one call site, and nothing else has to change. Option 1 is faster; option 2 is the one that stops this recurring.