basert: with no `--version`, install the newest baseRT release this build drives by IsuraManchanayake · Pull Request #31 · basecompute/superfluid

IsuraManchanayake · 2026-10-23T03:12:38Z

What changed

superfluid runtime install basert with no --version, and a serve that installs the basert runtime first, read baseRT's release listing first and install the newest release whose engine ABI marker (basert-engine-abi-<N>.txt) this build drives, pinned or not. A release that is not pinned is checked against the SHA-256 GitHub lists for its engine (the same digest baseRT publishes as <engine>.sha256); a pinned one keeps its pinned digest. Pre-releases are never the newest.
When the listing cannot be read, the pins answer as before, and the plan says so.
recipe.json pins 0.4.0 (ABI 1; both digests checked against the release's .sha256 files), so offline installs and superfluid runtime versions basert reach 0.4.0 too.
Changelog, the 0.1.4 release note, and the basert paragraph of docs/models/runtimes.md.

Why

The pins answered first, so a fresh install took 0.3.0, the newest pinned engine, and 0.4.0 was refused without --sha256, although 0.1.3's changelog says the newest release with this build's ABI number is taken. That also breaks --pull-file (#29) on a fresh install: it needs basert 0.4.1, and superfluid installed 0.3.0. With the newest taken from the listing, baseRT 0.4.1 is installed as soon as it is published, with no superfluid release in between.

How it was tested

New tests in recipe.rs: the newest driven release wins over the pins, by the listed digest; offline the newest pin; a listed release that is pinned keeps its pin; a pre-release is skipped; a release with no digest pinned or listed still needs --sha256, and a digest named wins. 16 pass.
With a fresh SUPERFLUID_HOME on an M5 Pro: runtime install basert --dry-run plans 0.4.0 from GitHub (c9b49ea1…), and 0.4.0 from the pins with the listing unreachable; superfluid serve --runtime basert --model basecompute/Qwen3-0.6B installed 0.4.0 by itself and answered a chat.
With rc-0.1.4 + basert: --pull-file takes one .base from a repo that holds several #29 + this: --pull-file Qwen3-0.6B-Q4.base against a baseRT rc-0.4.1 engine pulls with basert pull --file, finds the install by file and serves (chat and /v1/messages 200). Against the 0.4.0 engine it stops with basert's own "unexpected argument '--file'", so --pull-file needs 0.4.1 to be published.
cargo clippy --all-targets -- -D warnings (and -p superfluid --no-default-features)
cargo test: 133 binaries, 1500 passed, 0 failed
Changes a wire protocol, the WAL format or the tick ABI (it does not)

The basert half, where basert serve installs the newest superfluid rather than a fixed pin, is basecompute/baseRT-internal#773.

runtime install basert answered from the pins first, so a fresh install took 0.3.0, the newest pinned engine, and 0.4.0 was refused without --sha256, although 0.1.3's changelog says the newest release with this build's ABI number is taken. With no version named, the release listing is read first and the newest driven release wins, pinned or not, checked against the SHA-256 GitHub lists for its engine (the digest baseRT also publishes as <engine>.sha256). The pins answer offline, and 0.4.0 joins them. Pre-releases are never the newest.

IsuraManchanayake

Codex Review — joint review with basecompute/baseRT-internal#773

Reviewed d18bfae5f01705a5c82985ca15503e813df7e4db together with baseRT 4624265e34b6927437522c19f2cb48c99be76470. Two actionable issues are inline: the newly unconditional listing fetch has no deadline, so a stalled response never reaches the pinned fallback; and prerelease filtering also removes explicitly requested versions that the previous implementation accepted.

The ABI markers line up across the projects, and the two new 0.4.0 pin sizes/digests match GitHub's release metadata. Running the current planner against the live listing selected 0.4.0 / Metal with the expected c9b49ea1… digest. The baseRT launcher passes its engine and uses --offline, so the inspected handoff does not introduce a mutual-install loop. The documented requirement to publish baseRT 0.4.1 before expecting --pull-file to work remains relevant; ABI compatibility alone does not imply that CLI feature exists.

Validation: all 8 existing recipe tests passed, plus targeted before/after reproductions. The old recipe accepted an explicitly requested ABI-compatible prerelease with a supplied digest; the new recipe reports that no such engine is published. For the timeout case, a local TLS fixture returned successful HTTP headers and stalled the listing body: the previous planner returned a pinned plan in about 0.38s, whereas the new planner remained blocked after 8s and was terminated by the test harness. The spawned curl command has no connect/overall/low-speed deadline. All fixture processes were cleaned up.

Companion validation: baseRT's 11 superfluid-module tests and 12 launcher integration tests passed; that PR has a separately reproduced mirror asset-URL issue. Current CI checks on both PRs are green and both diffs pass git diff --check. No full joint server/inference run was performed.

IsuraManchanayake · 2026-10-23T04:59:46Z

+        return match fetch_json(recipe()["releases"].as_str().unwrap_or_default()) {
+            Ok(releases) => plan_with(req, host, &pins, &releases),
+            Err(listing) => {
+                let mut plans = plan_with(req, host, &pins, &Value::Null).map_err(|why| format!("{why} ({listing})"))?;


Codex Review — [P2] Bound the listing lookup before putting it ahead of the pins

Every unversioned install (including a fresh serve) now waits here before using a pinned release. fetch_json() in adapter-kit invokes curl without a connect timeout, overall timeout, or low-speed deadline, so a connection that succeeds but stops sending the listing can block forever; the Err branch that is supposed to provide the pinned fallback is never reached. I reproduced this using a local TLS fixture that sends HTTP 200 and then stalls its JSON body: the old planner returned its pin in ~0.38s, while the new one remained blocked until I terminated it after 8s. This affects users whose API connection stalls even when release assets are reachable. Give release discovery a bounded deadline and fall back to the pins on expiry before making it unconditional.

Accepted, fixed in e22a3ac. The fix is in the kit, since fetch_json is also what llama.cpp's release lookup and the speculator catalog call, and neither should block forever either. Every lookup now ends within 20 s, retries included (--connect-timeout, --max-time, --retry-max-time), and fetch_json_within(url, deadline) takes another deadline. When the listing times out, plan falls back to the pins as designed.

Failing first: a_json_lookup_that_stalls_gives_up_by_its_deadline points a lookup with a 2 s deadline at a socket that accepts and never answers. Without the flags it gave no answer within the test's 15 s; with them it returns an error in about 2 s. I also checked your case, HTTP 200 headers followed by a body that never comes, directly with curl and the same flags: it exits 28 at the deadline, with no retry past it.

IsuraManchanayake · 2026-10-23T04:59:46Z

        .map(|rs| {
            rs.iter()
-                .filter(|r| !r["draft"].as_bool().unwrap_or(false))
+                .filter(|r| !r["draft"].as_bool().unwrap_or(false) && !r["prerelease"].as_bool().unwrap_or(false))


Codex Review — [P2] Keep explicitly requested prereleases available

This filter runs before both the default selection and the Some(version) branch, so it changes more than which release counts as newest. An existing command such as runtime install basert --version 0.4.9 --untested --sha256 <digest> now reports that no engine is published when v0.4.9 is marked as a GitHub prerelease, even if its ABI marker and platform asset are present. A before/after test using that listing succeeds with the parent recipe and fails with this change. Apply the prerelease exclusion to automatic newest-version selection, while retaining explicitly requested releases and the existing compatibility/digest checks.

Accepted, fixed in 2dbb5a9. Pre-releases stay in the listing and are only left out of the default newest pick, so a named --version installs one again, with the usual ABI and digest checks.

Failing first: a_pre_release_is_installed_when_named_and_never_as_the_newest.

Named, ABI-compatible pre-release 0.4.8 with GitHub's digest: on d18bfae it failed with "baseRT publishes no basert 0.4.8 engine for macos-arm64"; now it plans 0.4.8 as tested, with that digest.

Default pick with 0.4.8 listed as a pre-release: still 0.4.7.

Pre-release of another ABI, named with --untested --sha256: plans as untested, with the given digest.

fetch_json ran curl with no deadline, so a listing that connects and then stalls blocked forever; with the basert listing now read ahead of the pins, that stopped a fresh install or serve from reaching the pinned fallback. Every lookup now ends within 20 s, retries included (--connect-timeout, --max-time, --retry-max-time), and fetch_json_within takes another deadline. Its test points a lookup at a socket that accepts and never answers: it blocked past 15 s before, and gives up in 2 s now.

The listing dropped pre-releases before both the default pick and a named --version, so runtime install basert --version <v> of a GitHub pre-release, which installed before, said no such engine is published. Pre-releases are now left out of the newest only.

IsuraManchanayake · 2026-10-23T05:12:25Z

Review handled. Both findings were right, and each is fixed with a test that failed on d18bfae (details in the threads):

e22a3ac: JSON lookups end by a deadline, so a stalled listing falls back to the pins.
2dbb5a9: a named pre-release installs again; it is never the default newest.

Re-run on 2dbb5a9: cargo clippy --all-targets -- -D warnings, -p superfluid --no-default-features, and the llama.cpp adapter and tokenizer configs are clean. cargo test: 1502 passed, 0 failed.

The companion finding on basecompute/baseRT-internal#773 (checksum URL derived from the tarball's directory) is fixed there in d7d78b16.

IsuraManchanayake changed the title ~~basert: with no --version, install the newest baseRT release this build drives~~ basert: with no --version, install the newest baseRT release this build drives Oct 23, 2026

IsuraManchanayake commented Oct 23, 2026

View reviewed changes

IsuraManchanayake added 2 commits October 23, 2026 16:08

IsuraManchanayake merged commit 6e85cd0 into rc-0.1.4 Oct 23, 2026
5 checks passed

IsuraManchanayake deleted the fix/basert-newest-engine branch October 23, 2026 05:21

Navigation Menu

Repository navigation

basert: with no `--version`, install the newest baseRT release this build drives - #31

basert: with no `--version`, install the newest baseRT release this build drives#31
IsuraManchanayake merged 3 commits into
rc-0.1.4from
fix/basert-newest-engine

IsuraManchanayake commented Oct 23, 2026 •

edited

Loading

Uh oh!

IsuraManchanayake left a comment

Uh oh!

IsuraManchanayake Oct 23, 2026

Uh oh!

IsuraManchanayake Oct 23, 2026

Uh oh!

IsuraManchanayake Oct 23, 2026

Uh oh!

IsuraManchanayake Oct 23, 2026

Uh oh!

IsuraManchanayake commented Oct 23, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

IsuraManchanayake commented Oct 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed

Why

How it was tested

Uh oh!

IsuraManchanayake left a comment

Choose a reason for hiding this comment

Uh oh!

IsuraManchanayake Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

IsuraManchanayake Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

IsuraManchanayake Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

IsuraManchanayake Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

IsuraManchanayake commented Oct 23, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

IsuraManchanayake commented Oct 23, 2026 •

edited

Loading