GeezerVison

Copy link

Copy Markdown

Collaborator

Mikola Lysenko (mikolalysenko) marked this pull request as ready for review October 5, 2026 18:21

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot reviewed Oct 5, 2026

View reviewed changes

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Tanmay Singla (Tanmay182003) approved these changes Oct 5, 2026

View reviewed changes

#646 landed inline sha1/sha256 computations in patch/jvm_jar.rs,
patch/sidecars/maven.rs and crawlers/gradle_cache.rs after the
utils::digest ratchet, so production_digests_go_through_the_helpers
fails on main. jvm_jar's private sha1_hex/sha256_hex copies and the
Maven sidecar's inline sha1 now call the shared helpers; gradle_cache.rs,
which an open PR also edits, joins the pending list for now. Hashes are
byte-identical.

Ported from #876 so this PR's CI is not red on the base-red ratchet.
(cherry picked from commit 28d4d52)

Assisted-by: Claude Code:claude-opus-5-5

No slot free (#876, #886, #889 ready); main and ranking unchanged.

Assisted-by: Claude Code:claude-opus-5-5

Capacity full (#876, #886, #889 ready). New tracking issue #930
and child #931 ranked; both skipped on file overlap.

Assisted-by: Claude Code:claude-opus-5-5

No free slot: #876, #886 and #889 are ready and approved. New #960
is skipped because commands/vendor.rs is changed by open PRs.

Assisted-by: Claude Code:claude-opus-5-5

The digest guard test (#865) fails on main. Gradle support landed with
inline sha256/sha1 computations in crawlers/gradle_cache.rs,
patch/jvm_jar.rs and patch/sidecars/maven.rs, and the guard's pending
list doesn't name them. List them as pending so CI is green until they
move onto the utils::digest helpers. Open PRs #876 and #889 add only
gradle_cache.rs.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HjNH36TbmyXCpJPw3EyBZB

Capacity is full (#876, #886, #889 ready), so this run only re-ranks.

Assisted-by: Claude Code:claude-opus-5-5

* Start fix for #424

Assisted-by: Claude Code:claude-opus-5-5

* Add failing tests for apply failures in --json

scan --mode agent --json and get --json report a failed nested apply
as failed: 0 with the patch listed as added and no error text. These
tests pin the expected envelope: the patch record carries
action: failed, errorCode and error, and failed counts it.

Refs #424

Assisted-by: Claude Code:claude-opus-5-5

* Report apply failures in scan/get --json

When scan --mode agent or get downloads a patch and the in-place apply
then fails, the --json output said failed: 0, listed the patch as
added and carried no error, so automation reading the JSON could not
tell what went wrong. Only the exit code and status hinted at it.

The nested apply now hands its failures back to the caller instead of
just a pass/fail flag. Each patch that failed to apply is reported as
action: failed with the same errorCode/error pair that apply --json
prints (apply_failed or package_not_installed), failed counts it, and
applied counts only patches that really applied. A failure that no
single patch explains (unreadable manifest, yarn PnP refusal, missing
patch sources) is reported as a top-level errorCode/error.

Fixes #424

Assisted-by: Claude Code:claude-opus-5-5

* Keep uninstalled patches as warnings in --json

When one patch fails to apply, apply only warns about other patches
that have no installed copy. The JSON report now matches that: those
patches are reported as package_not_installed failures only when
nothing else failed the run. Adds unit tests for the failure
collection.

Refs #424

Assisted-by: Claude Code:claude-opus-5-5

* Check composer/gem docker sync via the manifest

The composer and gem docker e2e scripts checked that scan's JSON said
"action": "added". In these fixtures scan's own in-place apply fails
(the later apply --force patches the file), and scan --json now
reports that failure on the patch record (#424). So "added" was only
there because of the bug. Check instead that the patch was recorded in
.socket/manifest.json, which is what "synced" means here.

Refs #424

Assisted-by: Claude Code:claude-opus-5-5

* Count only patches apply really applied

The --json apply failure report could blame the wrong patch and miscount
applied:
- a failure on one PyPI release variant was pinned on a selected
  sibling variant that applied fine, via a base-purl fallback;
- applied was "selected minus failed", so a selected patch that was
  never installed (only a warning next to a real failure) still counted
  as applied;
- get <uuid> zeroed applied whenever any other manifest patch failed,
  and its extra failure records had no uuid.

The nested apply now also reports which package keys it patched, and the
envelope counts applied from that. A failure only marks records it
covers: the same purl, or an unqualified key covering its variants.

Refs #424

Assisted-by: Claude Code:claude-opus-5-5

* Add the Gradle and Maven inline digests to the pending list

The digest guard test (#865) fails on main. Gradle support landed with
inline sha256/sha1 computations in crawlers/gradle_cache.rs,
patch/jvm_jar.rs and patch/sidecars/maven.rs, and the guard's pending
list doesn't name them. List them as pending so CI is green until they
move onto the utils::digest helpers. Open PRs #876 and #889 add only
gradle_cache.rs.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HjNH36TbmyXCpJPw3EyBZB

---------

Co-authored-by: Claude <[email protected]>

Main landed the #878/#876 digest-helper change for jvm_jar.rs and the
inline-digest ratchet in utils/digest.rs, so take main's version of both
files and drop this branch's ported copy; the PR now only changes the
vendor retry path in api/client.rs.

Co-Authored-By: Claude <[email protected]>

cursor Bot reviewed Oct 7, 2026

View reviewed changes

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot reviewed Oct 7, 2026

View reviewed changes

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

455 checks passed

Mikola Lysenko (mikolalysenko) deleted the arch-refactor/872-registry-timeouts branch October 7, 2026 15:24

…try (#677) (#889)

* Start refactor for #677

Assisted-by: Claude Code:claude-opus-5-5

* Retry vendor calls on api::retry's Retry-After

A vendor-service 429 or 503 that sent Retry-After as an HTTP-date
was retried on the 400 ms backoff, because the vendor path kept its
own delta-seconds-only parser. Vendor retries now read Retry-After
through api::retry::parse_retry_after on the client's RetryHooks
clock (still capped at VendorRetryPolicy::max_delay), and draw their
±25% jitter from the seeded api::retry::jitter_sample, keyed by
request and attempt, and wait on the hooks' sleep.

The private retry_after_secs and jitter_sample copies in client.rs
are deleted. New tests run the reference POST, the archive GET, the
capped artifact GET and a resumed deferred GET through the shared
parser, and pin the cap and the seeded jitter.

Assisted-by: Claude Code:claude-opus-5-5

* Route the JVM jar digests through utils::digest

#646 landed inline sha1/sha256 computations in patch/jvm_jar.rs,
patch/sidecars/maven.rs and crawlers/gradle_cache.rs after the
utils::digest ratchet, so production_digests_go_through_the_helpers
fails on main. jvm_jar's private sha1_hex/sha256_hex copies and the
Maven sidecar's inline sha1 now call the shared helpers; gradle_cache.rs,
which an open PR also edits, joins the pending list for now. Hashes are
byte-identical.

Ported from #876 so this PR's CI is not red on the base-red ratchet.
(cherry picked from commit 28d4d52)

Assisted-by: Claude Code:claude-opus-5-5

* Drop stale entries from the inline-digest ratchet

gradle_cache.rs, jvm_jar.rs and sidecars/maven.rs no longer compute
digests inline on main (they go through utils::digest), so
production_digests_go_through_the_helpers fails on the stale list. The
test's own doc says to drop a file once it moves onto the helpers.

Co-Authored-By: Claude <[email protected]>

---------

Co-authored-by: Claude <[email protected]>