SDK closure: decide separate offline installer pin vs runtime upgrade for expired-cache rollback preparation #6235
Unanswered
Yeachan-Heo
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Decision requested (test-build policy, not an implementation PR)
May the SDK rollback proof use a separately pinned Bun 1.4.1 dependency installer while keeping the host, native-build/embed and compiler on 1.4.0, or would maintainers prefer a separately qualified repository-wide upgrade?
Installer-only separation is the narrowest unproven design candidate, not an approved fix. It changes the existing single-toolchain preparation policy. No implementation or end-to-end host-1.4.0 success is claimed. No new public SDK runtime selector is requested.
Current contract and why a fixture-only bump is insufficient
Observed at PR #6019 head
be2dfda171bb4a6bc8f9c644dca905fb669ea1f1. I also read currentdev8cd17c0f636d3c541c0c2af184e01709b0e6f2c1: root remainsbun@1.4.0, and the rollback test and manifest are byte-identical to the PR head.manifest.toolchain.version === Bun.version.buncurrently selects all stages; changing a JSON version does not select a separate executable.aedd0df99e7c9dff420b50f7ff47bd6645627bdd, fresh isolated worktree, frozen install, newly compiled/host-signed executable, hash immediately before invocation. It is not a fixed prebuilt-binary contract.Changing only the fixture version to 1.4.1 was rejected by a real focused run on host 1.4.0: 0 pass / 1 fail / 2 filtered, line 229 (
Expected: 1.4.0,Received: 1.4.1). Deleting that assertion would weaken the proof, not establish installer/compiler isolation.Observations versus diagnosis
On macOS arm64, unchanged catalog-linked historical preparation fails under network denial with naturally expired cache: 1.4.0 attempts registry metadata lookup despite the existing
--offline --frozen-lockfileargv.A prior bounded investigation executed 16 install invocations (not 16 closure runs):
install.prefer = "offline",install.offline = true, or--prefer-offlineworkspace:*, matching lock literalBreakdown: 10 unchanged-graph 1.4.0 failures, 3 successful 1.4.1 installations, 1 negative 1.4.1 cache-miss control, 2 modified-graph 1.4.0 successes. Config/flag options and prepared node_modules did not solve this condition. These are reviewed execution receipts; I did not rerun the entire matrix for publication.
This is not a claim that every cache-only 1.4.0 install fails. The direct-workspace positive control succeeds. The graph reload plus metadata freshness explanation is supported by the controls and upstream changes; this does not isolate which upstream change alone suffices for the full historical graph.
Official primary sources, checked at version tags rather than substituting current docs:
install --help.The previously recorded 2651 pass / 0 fail whole closure used the task-local 1.4.1 candidate. It is not a host-1.4.0 closure pass and does not validate installer-only separation. No Linux/Windows execution is claimed.
Public minimal reproduction
Below is the actual sanitized script rerun for this publication, independent of private paths or source trees. Requires macOS
sandbox-exec, Python 3, official Bun 1.4.0/1.4.1 executables, and an existing complete cache containing the publicregexp-tree@0.1.27package and registry manifest whose freshness has naturally expired. A fresh cache may not reproduce the failure; an incomplete cache tests a different condition. Do not edit cache TTL/clock or rewrite cache bytes to manufacture expiry. The script does not warm/download dependencies. Use a disposable cache copy if you want to preserve your original cache.Save the following as
offline_repro.py, setBUN140,BUN141,CACHE, andSCRATCHto your own executable/cache/disposable-directory paths, then run:Fresh publication execution: official
1.4.0+34cbb9a40=> install exit 1/DNS failure; official1.4.1+4661e494f=> install exit 0/package present; 1.4.0 direct-workspace control => install exit 0/package present. All three retained source/lock bytes during installation. The Python harness exits normally and reports the install's exit in JSON. These are three additional minimal installations, not a full closure rerun.Executable minimal fixture and network-denied runner
Normal repository rollback entry point (requires the repository's provisioned native/build toolchains and pinned source object):
Use a disposable checkout and the same expired-cache/network-denied condition when comparing the historical install stage. A normal online run is not evidence for the offline case.
Scope needed if separation is accepted
bunin PATH.The synthetic
catalog:→workspace:*control is not a proposed historical-source normalization: doing that to the pinned source/lock changes what the rollback proof rebuilds. Skipping reinstall, using archived node_modules or a prebuilt binary similarly changes the proof. Whole historical runtime 1.4.1 also changes the compiled old binary's embedded runtime; it is not equivalent to installer-only separation.Duplicate/history comparison
Searched open issues/PRs and historical discussions for offline, toolchain, SDK downgrade, installer, 1.4.1, frozen lock, and catalog/cache. No existing discussion found that owns this expired-cache installer/runtime-split decision.
Please choose test-only installer separation versus a separately qualified repository-wide upgrade (or identify an existing supported policy that avoids both). This is a decision request, not a promise to implement either option. #6019 stays Draft/high-risk/needs-human; canonical validation and human review remain open.
—
[repo owner's gaebal-gajae (clawdbot) 🦞]
All reactions