Skip to content

ci(publish-runtime): use pip-resolve probe to bound cascade fan-out - #2197

Merged
HongmingWang-Rabbit merged 1 commit into
stagingfrom
fix/cascade-pip-resolve-propagation
Apr 28, 2026
Merged

ci(publish-runtime): use pip-resolve probe to bound cascade fan-out#2197
HongmingWang-Rabbit merged 1 commit into
stagingfrom
fix/cascade-pip-resolve-propagation

Conversation

@HongmingWang-Rabbit

Copy link
Copy Markdown
Contributor

Summary

Closes #130. The cascade's PyPI-propagation gate polled /pypi/<pkg>/<ver>/json — one of three surfaces pip touches. The other two (/simple/ index and files.pythonhosted.org CDN) have independent caches, so the gate could let the cascade fire while pip in the receiver templates still resolved to the OLD wheel, then docker layer cache locked the stale resolution in.

Fix

Replace the metadata-only curl poll with an actual pip install --no-cache-dir --force-reinstall --no-deps PACKAGE==VERSION from a fresh venv. Pip is the ground truth for what every receiver will see — if it can resolve the exact version we just published, every template's runtime-published.yml will too.

Per-poll cost: ~3-5s (venv created once outside the loop; only the pip install runs in the poll body). Loop budget: 30 × 4s ≈ 2 min, generous vs typical propagation.

Verification

Locally:

  • Probing version 0.1.999999 (non-existent) → pip exits 1, loop would retry. ✓
  • Probing version 0.1.29 (current PyPI-latest) → pip exits 0, pip show returns matching version, loop would succeed. ✓

Test plan

  • CI green on this PR
  • On the next staging push that triggers publish-runtime.yml, observe the cascade's "Wait for PyPI to propagate" step shows the new poll (pip resolves molecule-ai-workspace-runtime==X.Y.Z after N poll(s))
  • Confirm receiver templates' subsequent builds use the new runtime version

🤖 Generated with Claude Code

The cascade's PyPI-propagation gate polled `/pypi/<pkg>/<ver>/json`,
which is one of THREE surfaces pip touches when resolving an install:

  1. /pypi/<pkg>/<ver>/json    — metadata endpoint (the old check)
  2. /simple/<pkg>/             — pip's primary download index
  3. files.pythonhosted.org     — CDN-fronted wheel binary

Each has its own cache. Any one of them can lag behind the others,
and the previous gate would let the cascade fire while (2) or (3)
still served the previous version. Downstream `pip install` in the
template repos then resolved to the OLD wheel, the docker layer
cache locked that stale resolution in, and subsequent rebuilds kept
shipping the old runtime — the "five times in one night" cache trap
referenced in the prior comment.

Replace the metadata-only poll with an actual `pip install
--no-cache-dir --force-reinstall --no-deps PACKAGE==VERSION` from
a fresh venv. If pip can resolve and install the exact version we
just published, every receiver template will too — pip itself is
the ground truth for what the receivers will see, no proxy guessing
about which surface is lagging.

  - Venv created once outside the loop; only `pip install` runs in
    the poll body.
  - --no-cache-dir + --force-reinstall ensures every poll hits the
    live PyPI surfaces (no local-cache mask).
  - --no-deps keeps each poll fast — we only care about resolving
    THIS package, not its dep tree.
  - Loop budget: 30 attempts × 4s ≈ 2 min (vs prior 30 × 2s = 60s).
    Generous vs typical PyPI propagation, surfaces real upstream
    issues past the budget.

Verified locally:
  - Probing a non-existent version (0.1.999999) → pip exits 1, loop
    retries.
  - Probing the current PyPI-latest → pip exits 0, `pip show`
    returns the version, loop succeeds.

Closes #130.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@HongmingWang-Rabbit
HongmingWang-Rabbit added this pull request to the merge queue Apr 28, 2026
Merged via the queue into staging with commit 2f6fe9a Apr 28, 2026
15 checks passed
@HongmingWang-Rabbit
HongmingWang-Rabbit deleted the fix/cascade-pip-resolve-propagation branch April 28, 2026 15:29
HongmingWang-Rabbit pushed a commit that referenced this pull request Jun 12, 2026
…gression for moonshot/kimi NOT_CONFIGURED' (#2197) from test/provider-matrix-boot-regression-moonshot into main
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant