Skip to content

Move the vendoring-service client out of api/client.rs into its own submodule #871

Description

[agent] Filed by the scheduled architecture audit routine (CLI and core). Register: register comment.

Kind: refactor (a mechanical move). Source: review Part 7.2 and 7.6 #8, register row C29. This is the first of two moves; the second moves credential resolution out (see Dependencies).

Problem (main @ 0d302dc)

api/client.rs is 6,033 lines: 2,918 production lines, then five test modules. It holds three separate clients behind one impl ApiClient:

  1. The patch API JSON client: send_json_request, search, batch, fetch_patch, and blob/diff fetch_binary (L496–L1183).
  2. The vendoring-service client, about 895 production lines in three separate places:
    • fetch_vendor_package through download_artifact_resuming and DeferredAttempt: L1185–L1830;
    • its types (MAX_VENDOR_PACKAGE_BYTES, FetchedVendorPackage, SecondaryArtifact, PlannedDownload, PrefetchedSecondary, VendorServiceOutcome, ServeDownload, artifact_download_result): L1834–L1970;
    • a second impl ApiClient after the PatchApi seam (download_artifact_capped, download_artifact_capped_once, CappedAttempt): L2790–L2906;
    • plus its retry policy (VendorRetryPolicy, VENDOR_BREAKER_THRESHOLD, MAX_REFERENCE_BATCH, PYPI_NOT_A_WHEEL, wheel_filename_from_url): L282–L391.
  3. Credential and env resolution: ApiClientEnvOverrides, get_api_client_*, resolve_*credentials*, token-shape checks and build_proxy_fallback_client (L2036–L2364).

The vendor tests are just as large: vendor_package_tests has 766 lines and vendor_retry_tests has 762.

Because the vendor client is split across three places in the file, its retry loop (VendorRetryPolicy, three retry_after_secs call sites) is hard to review next to the JSON loop. That is the work #676 and #677 need to do.

Symptoms

None filed. Impact: maintainability. Every change to the patch API client and every change to the vendor service lands in the same file. The C15 retry work (#676, #677) and the C9/C39 proxy fallback work (#647) all edit this file.

Proposed change

  • Create api/client/vendor_service.rs as a child module of client, so the moved code keeps access to ApiClient's private fields and helpers without any visibility changes. This means turning client.rs into client/mod.rs, or adding #[path].
  • Move all the vendor-service items listed above, with their own impl ApiClient block, into it.
  • Move vendor_package_tests and vendor_retry_tests into a sibling api/client/vendor_service_tests.rs, included with #[cfg(test)] #[path] mod.
  • Re-export the public names from client so no import outside api/ changes.
  • Deleted from client.rs: the second impl ApiClient block after the PatchApi seam, and every vendor-only item. client.rs keeps the JSON client, fetch_binary, the error type and the PatchApi seam.

There are no behavior changes, renames or signature changes. retry_after_secs and jitter_sample() move as they are; #677 deletes them.

Size and scope

Acceptance criteria

  • grep -c "fn fetch_vendor_package\|fn download_artifact_capped\|struct VendorRetryPolicy" crates/socket-patch-core/src/api/client.rs (or client/mod.rs) prints 0.
  • client.rs/client/mod.rs has one production impl ApiClient block for the JSON client, plus the PatchApi impl.
  • git diff -M --stat shows the moved tests as moves, and no test bodies changed.
  • cargo test -p socket-patch-core --lib api:: passes, as do api_retry_e2e, api_timeout_e2e, binary_fetch_error_classification_e2e and the vendor prefetch tests, with the same test count before and after.
  • cargo clippy --workspace --all-features -- -D warnings is clean.

Dependencies

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent:triagedarch-auditFiled by a scheduled architecture audit routine (see the architecture review discussion)priority:p3refactorStructural change: duplicated code or logic, missing abstraction, layering, dead code

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions