ReviewOS

pantry-pm/pantry

fix(registry): keep native metadata reads available during deploys

#249
Open chris opened this 8 days ago ·
8 days ago

A real native Android-tools installation failed during registry deployment. Its original source-CLI evidence is retained in CI job 120622371117.

The installation ran from 2026-10-23 19:54:59 UTC through 19:56:29 UTC. It exhausted the maintained registry GET retries with HTTP 502 for github.com/google/brotli, sourceware.org/bzip2, and freedesktop.org/fontconfig metadata. The concurrent deployment recorded no local response at 19:55:41, scanner warming at 19:55:49, and public readiness HTTP 200 at 19:55:53. The buffered CLI log establishes overlapping installation and restart intervals; it does not give an exact timestamp for each HTTP request. All three public metadata endpoints returned HTTP 200 when inspected again at 20:01:46 UTC.

Original failed-Android artifact: 12528436415, SHA-256 285a5c95ac6e7ef7729fb460bb01706c960362dc0639861c110114ea940f29c1. Its complete original ZIP, CRCs, logs, and cleanup receipt are retained locally. Candidate v0.11.121 publication was cancelled before any GitHub release existed and is not qualified for downstream adoption.

Source commit 15c99fa2cec89dbbc1fe9d532a8ee62edc47e803 now requires all 14 exact-source main CI jobs before deployment or publication. This prevents deployment from running ahead of source acceptance. It does not remove the production restart availability gap.

The current deployment updates its checkout/build in place and restarts the live registry and scanner. Fix the owning service/deployment lifecycle using maintained native capabilities before consuming them. Preserve co-hosted rpx routes and scanner fail-closed behavior.

Acceptance:

  • Prepare and verify an immutable candidate before changing live traffic.
  • Keep existing native metadata reads available throughout rollout, without increasing client budgets, adding retries to CI, bypassing the registry, or substituting cached fixtures.
  • Switch traffic only to a ready candidate and drain the prior instance safely. Account for in-flight publication and snapshot-backed metadata so rollout cannot lose or overwrite accepted state.
  • A failed candidate leaves the previous healthy service serving requests.
  • Retain real HTTP execution through the deployment/proxy boundary, including an intentionally unhealthy candidate and sustained native metadata requests. Verify zero transport/502 failures and unchanged artifact identities.
  • Preserve scanner requirements, active publication/response deadlines, per-app gateway ownership, and other tenants' traffic.
  • Keep this issue open until actual rollout evidence demonstrates availability. CI ordering alone does not close it.

Sign in to comment on this issue.