Run 25546676715 / job 74984469728 (Windows Studio UI CI / Chat UI Tests)
broke on the previous commit (2843e2a9). Symptom:
install.log: "frontend up to date"
studio.log: FileNotFoundError:
D:\\a\\unsloth\\unsloth\\studio\\frontend\\dist\\index.html
Playwright: TimeoutError waiting for "#new-password" (60s)
Root cause: the Pre-install Windows tweaks step's loop did
if (-not (Test-Path $p)) { New-Item -ItemType Directory -Force -Path $p }
Add-MpPreference -ExclusionPath $p
before install.ps1 ran. That created an empty studio/frontend/dist
directory whose mtime was newer than every source file. setup.ps1's
mtime-based "is the frontend stale?" check at studio/setup.ps1
line 1281-1296 then concluded "frontend up to date, skip rebuild",
so vite never wrote anything into dist. Studio booted with an empty
dist directory and crashed on GET /change-password (the static-file
handler at studio/backend/main.py:489 read_bytes()'d a non-existent
index.html).
The same trap broke the frontend-dist actions/cache attempt earlier
in this branch (commit d65f8b19 -> reverted in e1345d5f). Same root
cause: any process that puts a fresh-mtime directory at
studio/frontend/dist before the build silences the Vite rebuild.
Fix: drop the New-Item call. Add-MpPreference accepts paths that do
not yet exist; the exclusion is registered and applies when the path
materialises. The failure is bisected to this single line, and reverting
just that line restores green.
Applied identically to all 4 Windows workflows so api/ui/update/inference
jobs all stay green.
Side-by-side substep timing (Update CI, same SHA, post cache-revert):
Mac Linux Windows
install uv 1s 1s 12s
uv pip install unsloth 8s 10s 29s
Node setup 4s 4s 35s <- winget reinstall
frontend build 20s 22s 204s <- 10x slower
9-step uv pip deps 15s 20s 92s <- 5x slower
llama.cpp validate 38s 21s 13s
-------------------------------------------------
total 96s 93s 400s
Two Windows-specific time sinks have nothing to do with the install
logic itself; they are runner-environment friction:
(1) `setup.ps1` line 1109-1145 requires Node 22.12+ AND npm >=11
(Vite 8 hard requirement). actions/setup-node@v4 with
`node-version: '22'` lands Node 22.22.2 + the npm 10.9.7 it
bundles, so the npm check fails and setup.ps1 falls into the
"winget install Node.js LTS" branch (~35 s) for a Node reinstall
we do not actually need. `npm install -g npm@^11` upgrades the
bundled npm in-place in ~5 s, which lets setup.ps1 short-circuit
on the existing Node 22.
(2) windows-latest's Windows Defender real-time scanning opens and
hashes every file the install writes. Vite/Tailwind/TSC produce
thousands of small chunks during the frontend build, and uv pip
extracts thousands of small files per wheel. The scan latency
dominates both. Adding Add-MpPreference -ExclusionPath entries
for the four directories Studio writes to drops per-file open
latency from ~ms to ~us. The runneradmin user has the privilege
needed; wrap each call in try/catch so a permission flake leaves
the install otherwise unaffected.
Excluded paths:
$env:USERPROFILE\.unsloth (Studio venv + llama.cpp)
$env:USERPROFILE\AppData\Local\uv (uv wheel cache + extracts)
$env:GITHUB_WORKSPACE\studio\frontend\node_modules
$env:GITHUB_WORKSPACE\studio\frontend\dist
Six Windows jobs touched (4 workflows, with the inference workflow
fanning out to 3 jobs):
studio-windows-update-smoke.yml (1 job)
studio-windows-api-smoke.yml (1 job)
studio-windows-ui-smoke.yml (1 job)
studio-windows-inference-smoke.yml (3 jobs: openai-anthropic,
tool-calling, json-images)
The new "Pre-install Windows tweaks" step is identical across every
Windows job; the rationale is described once in
studio-windows-update-smoke.yml and cross-referenced from the others.
Expected savings per Windows job:
- npm fix: ~35 s saved (winget Node reinstall skipped)
- Defender exclusions: ~30-90 s saved (frontend / uv-pip-extract)
- Combined: ~60-120 s per job, or ~6-12 min CPU per PR push across
all 6 Windows jobs.
Not addressed (out of scope for this commit):
- The fundamental Vite/TSC/Tailwind frontend build cost on NTFS.
Optimising that would mean changing the build pipeline (e.g.
skipping `tsc -b` and relying on type-check elsewhere), which is
much more invasive.
- The uv pip extraction cost. The actions/setup-python@v5 cache
already caches pip wheels; uv has its own cache that we could
cache separately, but the cache restore overhead on Windows
(76 s for the venv we tried and reverted) tends to eat the
savings -- the Defender exclusion above goes after the same
cost via a different lever.
The "Tool calling, server-side tools, thinking on/off" step was the
single largest cost in the inference smoke jobs:
Mac: 338s (the user complaint)
Linux: 176s
Windows: 85s (variance bounded; macos runner is ~10 tok/s vs ~30 tok/s)
Two surgical cuts that preserve all distinct coverage axes:
(1) Drop the dedicated "Server-side bash (terminal) tool" axis. The
python-tool axis above already exercises the same server-side
agentic-loop wiring (SSE streaming + tool dispatch + tool-result
re-prompting); the only difference between the two axes is which
entry of the tool registry resolves: python_run vs terminal_run.
Studio's terminal tool has its own unit tests under
tests/studio/test_terminal_tool*.py; the smoke axis was duplicated
coverage. Saves one full SSE round per job (~30 s on macos, ~12 s
on linux/windows).
(2) Halve max_tokens on the remaining 4 axes. The previous numbers
(300-600 across the board) were 2-4x what each prompt actually
needs to land an answer. New caps:
function calling: 300/120/600 -> 128/96/128 (mac/linux/win)
python tool: 256/600/600 -> 128/320/320
web_search: 200/400/400 -> 96/192/192
thinking on/off: 150/300/300 -> 80/160/160
All assertions are unchanged. function calling stays grammar-
constrained by tool_choice='required'; python tool stays gated on
"56088" appearing in the SSE stream; web_search stays a
non-blocking probe; thinking on/off stays gated on the think
marker behaviour.
Expected wallclock:
Mac 338 -> ~170 s (target: -50%)
Linux 176 -> ~80 s
Windows 85 -> ~50 s
If a real Studio regression slips through, the linux/windows axis
still has the hard `assert "56088" in content` (python tool agentic
loop). The python axis remains the canonical proof that tool dispatch
+ tool-result re-prompting both work.
The "llama.cpp install via unsloth_zoo.llama_cpp" step ran inside every
cell of the consolidated `Core` matrix (HF=4.57.6+TRL<1, HF=latest+
TRL=latest, HF=default+TRL=default) at ~275 s wallclock per cell. The
artefact it produces (a fresh ggml-org/llama.cpp build) has nothing to
do with the (transformers, TRL) combo, so 2/3 of those minutes were
duplicated work -- ~9 min of CPU per PR push, on every push.
Factor the step into a sibling job `llama-cpp-smoke` that runs once.
Each Core cell now ends after the matrix-relevant work (deps + Bucket-A
+ unsloth_zoo pytest + compile sweep + MoE patches). The new job pins
the same env contract (UNSLOTH_IS_PRESENT, UNSLOTH_COMPILE_DISABLE,
PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python, PYTHONPATH=studio) and
mirrors the matrix install minus pieces unrelated to llama_cpp:
studio.txt's FastAPI stack, bitsandbytes, triton, mammoth/unpdf,
datasets, pytest, sqlalchemy/cryptography. Keeps torch from the same
CPU index, transformers/trl from pyproject defaults (so unsloth_zoo's
temporary_patches.* per-architecture submodules import cleanly), and
the requests / tqdm / psutil that llama_cpp.py reaches for at module
top.
Net per-PR effect:
Old: 3 x 12 min = 36 min CPU on llama.cpp build (one cmake per cell)
New: 3 x 7 min + 1 x 7 min = 28 min CPU
That's ~8 min of free CPU back per PR, and each Core cell finishes
~5 min sooner so downstream-gated checks unblock faster.
The actual smoke step body is unchanged -- same `_zoo_aggressive_cuda_
spoof.apply()` import-time harness, same `install_llama_cpp` round-
trip, same `llama-cli --help` and `llama-quantize --help` text checks.
Per-step `continue-on-error` is still absent; a real build failure
fails the PR.
The cache plan added in d65f8b19 was meant to shave ~5min off Windows
install time, but a controlled rerun on the same SHA shows it doesn't.
Side-by-side timing of the install step (cache miss vs cache hit on the
same Windows Update CI job, same workflow, same source):
cache miss (385s) | cache hit (450s, +65s slower)
----------------------- | -----------------------------
Cache restore 1s | 83s (76s Studio venv + 4 + 3)
Frontend build 159s | 204s ("Frontend source changed since
| last build -- rebuilding...")
PyTorch + 9 deps 81s | 95s
llama.cpp install 39s | 13s ("prebuilt up to date and validated")
Cache save (post) 17s | 0s (no upload, hash matched)
Root causes:
1. The Studio venv cache is a no-op. install.ps1 line 1097-1120 sees the
cached venv, calls Start-StudioVenvRollback to MOVE it aside as a
rollback backup, then unconditionally creates a fresh venv at line
1167. Cache restore costs 76s for a 398MB venv that is then thrown
away.
2. The frontend dist cache is a no-op. setup.ps1 line 1281-1296 checks
`LastWriteTime > $DistTime` for every source file. git checkout sets
all source mtimes to "now" while restored dist mtimes are from
cache-creation time, so the staleness check always wins and rebuilds.
3. Only the llama.cpp prebuilt cache works (saves ~26s). Not enough to
offset the other two.
Reverting the cache plan is safer than partially fixing it and waiting
for a follow-up to land. install.ps1 + setup.ps1 would both need
modification to make the cache useful, and that change touches all
platforms. The non-Windows mirrors of these workflows (-mac-, regular
linux) never had cache steps, so this revert restores parity.
The four other commits in this branch (Recents click bound, jq health
check, sys.stdio explicit handles, setup.ps1 stdout mirror, single-
process Chromium darwin-only, github_blob_to_raw netloc check) all
remain.
Windows Studio install (install.ps1 --local --no-torch) is the
second-biggest cost on PR 5312 after the Recents-step fix:
Windows Studio UI CI: 414s install (of 24m47s wallclock)
Windows Studio Update: 414s install (of 9m28s)
Windows Studio API: 379s install (of 7m48s)
Windows Studio GGUF (x3): 353s..429s install
Of that 6-7 min, ~3.5 min is uv pip install of the studio venv,
~45s is npm ci + vite build of studio/frontend/dist, ~30s is the
llama.cpp prebuilt fetch+extract; ~90s is winget bringing system
tools in (Python, uv, Node, git, cmake, VS, bun) which sits at
the runner-image layer and isn't cacheable from a workflow.
Add three actions/cache@v4 entries before the install step in
each Windows workflow:
- ~/.unsloth/studio/unsloth_studio (the studio venv)
keyed on hashFiles(pyproject.toml, studio/backend/requirements/**,
install.ps1, studio/setup.ps1, studio/install_python_stack.py)
- ~/.unsloth/llama.cpp (the prebuilt llama.cpp tree)
keyed on hashFiles(studio/install_llama_prebuilt.py)
- studio/frontend/dist (the vite build output)
keyed on hashFiles(studio/frontend/package-lock.json,
studio/frontend/src/**, studio/frontend/index.html,
studio/frontend/vite.config.*, studio/frontend/tsconfig*.json,
studio/frontend/components.json)
Security:
* Cache keys are content-addressable hashes of every input file
that meaningfully changes the produced artefact. A malicious
PR that modifies any of those triggers a fresh build; the
cache cannot mask a real dependency change.
* GitHub Actions cache is branch-partitioned -- a PR cache
cannot poison main's cache. Only a successful build on main
can populate the main-branch cache.
* No restore-keys: prefix-matched fallback would resurrect a
venv whose lockfile no longer matches; uv pip install would
then silently keep the old packages. We want all-or-nothing
on lockfile hash.
* The cache version salt (-v1-) lets us invalidate every entry
immediately if a future advisory or build-system change
requires it.
setup.ps1 already takes the "reusing existing virtual environment"
fast-path when ~/.unsloth/studio/unsloth_studio exists, and the
"prebuilt up to date and validated" fast-path when llama.cpp is
already laid down -- no setup.ps1 changes needed.
Estimated saving: ~5 min per Windows job, ~30 min compute per PR
when caches hit. First run on each lockfile change still pays the
full install cost (the cache-miss path is unchanged).
The "Recents: click previous chat in sidebar" step in
tests/studio/playwright_chat_ui.py was the single biggest wallclock
sink across all three UI workflows on PR 5312:
Linux Studio UI CI: 786s in this one step (out of 823s Drive chat UI)
Windows Studio UI CI: 786s in this one step (out of 825s)
Mac Studio UI CI: 1389s in this one step (out of 1542s)
Root cause was the text-filtered selector
aside a, aside button, [data-sidebar=sidebar] a, ...
plus an EXCLUDE regex anchored start...end that didn't match the
coalesced sidebar text the app actually renders (unslothBETA,
UUnslothUnsloth, Train, Export, Recents). The loop kept
clicking those nav links, the post-click page.evaluate threw on
the navigated frame, the bare except: continue swallowed the
error, and the loop iterated forward where each candidates.nth(i)
hit Playwright's default 60s per-locator retry against a now-stale
DOM. Mac under single-process Chromium ate about 22 of those retries.
Server-side studio.log was idle for the entire 23-min window --
the time was spent in the browser.
Fix:
1. Add data-testid=recent-thread to the actual chat-history
SidebarMenuButton in studio/frontend/src/components/app-sidebar.tsx
(the live one; thread-sidebar.tsx is dead code, no imports).
Also add data-thread-type / data-thread-id for richer assertions.
2. Switch the Playwright selector to that testid, drop the
text-match heuristic + EXCLUDE regex.
3. Bound the whole step with a 30s deadline + 5-iteration cap +
5s click timeout, so a misbehaving selector cannot blow up
wallclock the way the previous loop did.
Verified locally on Linux + headless Chromium:
PASS: rendered 2 [data-testid=recent-thread] entries
PASS: clicked recent inside deadline (about 0.6s used)
PASS: bogus selector exits in 5s
Test driver at tests/scripts/repro_recents_local.py.
Expected savings on PR 5312:
Linux UI 18m36s to about 5m
Windows UI 24m47s to about 12m (still has about 7m install)
Mac UI 31m10s to about 9m
Total about 50 min compute and 22 min PR wallclock per PR.
The "Boot Studio briefly to confirm the install is still usable" step
writes /api/health to /tmp/health.json from MSYS Git Bash and reads it
back with `python -c "json.load(open('/tmp/health.json'))"`. Git Bash
on windows-latest resolves /tmp against the MSYS root, while the
setup-python interpreter is Windows-native and resolves /tmp against
the current drive's root. The two paths don't agree, so python's
open(...) fails with FileNotFoundError even though curl just wrote
the file.
Switch to `jq -e '.status == "healthy"' /tmp/health.json`. jq is a
Git Bash builtin so it reads through the same MSYS path and finds
the file. Mirrors studio-windows-api-smoke.yml,
studio-windows-ui-smoke.yml, and
studio-windows-inference-smoke.yml.
Failure surfaced once the upstream "unsloth studio update" step
started actually emitting output to update.log (run 25534895087 /
job 74948624523).
The previous Write-Host capture attempts (47432b0b -Command + *>&1
and f2c2b3f3 [Console]::Out mirror in setup.ps1) still produced an
empty update.log on windows-latest because the powershell.exe child
had no stdio handles at all to write to.
Root cause: subprocess.run on Windows with the default close_fds=True
(Python 3.7+ default) sets bInheritHandles=False on CreateProcess.
Combined with CREATE_NO_WINDOW (added by _windows_hidden_subprocess_
kwargs in non-TTY runs), the child gets:
- no console (CREATE_NO_WINDOW)
- no inherited std handles (bInheritHandles=False)
GetStdHandle in the child returns INVALID_HANDLE_VALUE, so even
[Console]::Out.WriteLine and Write-Output -- not just Write-Host --
write into the void.
Fix: pass stdout=sys.stdout, stderr=sys.stderr (and stdin) when
running the setup script on Windows. With explicit handles, Python's
subprocess sets up PROC_THREAD_ATTRIBUTE_HANDLE_LIST containing the
std handles + bInheritHandles=True, so the child inherits exactly
the three std handles regardless of close_fds=True. CREATE_NO_WINDOW
still applies (no transient console window), but the child can now
write to the inherited stdout file handle, which lands on bash's
`tee logs/update.log` in CI.
A small _stream_for_subprocess helper guards against test harnesses
that swap sys.stdout for a stream without a real fileno (pytest
capsys, in-memory IO buffers, etc) -- those fall back to None so
subprocess uses its default.
Verified locally on PowerShell 7.4.6 / Linux that the explicit
stdout handoff doesn't regress the existing direct-inherit path,
and the marker line "prebuilt up to date and validated" reaches
both the child's stdout and a parent `tee` consumer.
Follow-up to 47432b0b. The -Command + *>&1 redirect at the
powershell.exe invocation level is not enough on its own: PS 5.1's
Write-Host writes via $Host.UI.WriteLine, and the default ConsoleHost
does not always forward host-UI output to the inherited stdout
handle when there is no console attached (CREATE_NO_WINDOW) and
stdout is a pipe. Even with $InformationPreference = 'Continue',
the parent's `tee` saw nothing, so `unsloth studio update --local
2>&1 | tee logs/update.log` produced an empty update.log.
Add a small Write-StudioStdoutMirror helper and have step/substep
mirror the plain (no ANSI) form of each line to [Console]::Out
when [Console]::IsOutputRedirected is true. [Console]::Out always
lands on the OS-level stdout file handle, so the line propagates
through install.ps1 -> unsloth.exe -> python -> powershell.exe ->
setup.ps1 unaffected by host-UI vs information-stream quirks.
Gated on IsOutputRedirected so the interactive-console UX stays
unchanged (no double-printing of the colorized step lines).
Net effect: the Windows Studio Update CI's grep for "prebuilt up to
date and validated" / "prebuilt installed and validated" finds the
marker because step() now writes the plain text to stdout from
inside setup.ps1.
CodeQL flagged scripts/notebook_to_python.py:33's
`if "github.com" in url and "/blob/" in url` as
py/incomplete-url-substring-sanitization: "github.com" can sit
anywhere in the URL, so an attacker-controlled URL like
https://attacker.example.com/github.com/blob/x would be rewritten
to a raw.githubusercontent.com URL and fetched as if it were a
real GitHub blob.
Switch to urllib.parse.urlparse and require parsed.netloc ==
"github.com" exactly, then rewrite via a proper urlunparse on the
parsed components (path is replaced with first /blob/ -> / only).
Query strings and fragments now round-trip correctly too, which
was an incidental bug in the old string-replace path.
Closes the high-severity CodeQL alert on PR head 08235625.
Chat UI Tests on windows-latest were dying at composer.wait_for(...)
with playwright TargetClosedError "Locator.wait_for: Target page,
context or browser has been closed". studio.log shows a clean POST
/api/auth/change-password 200 followed by zero further requests --
the page died as soon as the React app navigated after the
change-password submit. The root cause is the --single-process
Chromium flag in _CHROMIUM_STABILITY_ARGS: it was added in commit
fdf7f94f for the macos-14 free runner, where the browser <-> renderer
IPC pipe was the actual crash site, but on windows-latest the IPC
pipe is fine and forcing single-process strictly destabilises the
browser -- any in-flight renderer crash takes the whole context
down because there is no separate renderer process to recover into.
Make the flag conditional on sys.platform == "darwin" in both
playwright_chat_ui.py and playwright_extra_ui.py. Linux currently
passes either way today, so we mirror the original commit's stated
intent ("ci(mac): single-process Chromium") and only opt darwin in.
The accompanying timeout / screenshot-best-effort comments stay
correct -- they describe darwin-specific slowness that is still
real on the macos-14 runner.
Failing run for the record: 25522501202 / job 74909947457.
`unsloth studio update --local 2>&1 | tee logs/update.log` was
producing an empty update.log on windows-latest because
_run_setup_script() invoked powershell.exe -File studio/setup.ps1.
setup.ps1 emits every step/substep line via Write-Host, which on
PowerShell 5+ lands on the Information stream (#6) and is NOT
merged into stdout when -File is used and the parent's stdout is a
pipe. The bash tee in CI therefore saw nothing, and the post-step
grep for "prebuilt up to date and validated" failed with
::error::no prebuilt up-to-date marker in update.log.
Switch the Windows branch from -File to -Command, with the script
path single-quoted (apostrophes escaped per PowerShell rules) and
followed by *>&1 so all six PS streams (stdout, stderr, warning,
verbose, debug, information) are merged into the success stream.
That stream is then inherited by the Python subprocess and reaches
the parent's stdout pipe verbatim.
This also makes the install.ps1 -> unsloth.exe -> setup.ps1
grandchild output visible at install time for the first time, so
logs/install.log gains the existing "prebuilt installed and
validated" marker. The Windows-update workflow's filesystem-based
fallback is unchanged and still works.
Mac is untouched (still uses bash setup.sh -- plain stdout).
Run 25497245250 / job 74820324136 (commit f3e541d) failed with:
Page.fill: Timeout 60000ms exceeded.
Call log:
- waiting for locator("#new-password")
This was AFTER `page.locator("#new-password").wait_for(state="visible")`
returned successfully. So the element WAS visible at that moment,
then disappeared from the DOM 60s before page.fill could grab it.
Root cause: on macos-14 free runners under --single-process
Chromium, the change-password page's bootstrap-state poll
(/api/auth/status) and React router both finish AFTER wait_for()
returns. If they decide the user is "already authenticated" or
"no longer must change password", the route rerenders and the
#new-password input is unmounted. Page.fill then waits the full
60s for an element that's gone.
Two changes (both playwright_chat_ui.py and playwright_extra_ui.py):
1. Add `page.wait_for_load_state("networkidle", timeout=30_000)`
AFTER page.goto, BEFORE wait_for(). This lets the bootstrap
dispatch settle so the route is committed before we touch the
form. Wrapped in try/except so a slow `networkidle` (e.g. SSE
keepalives) doesn't block forever -- best-effort.
2. Drop the `shoot("01-change-password-initial")` call between
wait_for() and fill(). The screenshot's font-load wait is
another window for the React form to detach. The
`02-change-password-filled` shoot AFTER the fill is sufficient
for diagnostics. Use locator API + explicit per-call timeouts.
The api-introspect job was pulling PyPI's `unsloth` via
`pip install --no-deps unsloth`. Latest released PyPI unsloth lacks
the CPU-torch fallback in unsloth/kernels/utils.py (lines 162-170)
that this branch carries, so `import unsloth` crashes with
AttributeError on `torch._C._cuda_getCurrentRawStream` (CPU torch
doesn't compile that symbol).
Switch to `pip install --no-deps -e ./unsloth` so the api-introspect
job validates the code in THIS PR head, not whatever's currently on
PyPI. unsloth_zoo continues to come from PyPI since the PR doesn't
modify unsloth_zoo.
Tick 3 of api-introspect failure: triton install fixed the previous
crash, now `import unsloth` reaches unsloth.models._utils which pulls
unsloth_zoo.vision_utils (line 147), which imports PIL (line 57),
which is not installed.
Mirror the consolidated-tests-ci.yml install: pull torchvision from
the CPU wheel index (this normally drags in Pillow), and add Pillow
+ safetensors + tqdm + packaging + psutil explicitly as
belt-and-braces in case torchvision drops its Pillow dep on a future
release.
Run 25494926834 (commit 1b92a8b's Mac UI run) showed the screenshot
fix worked -- "Drive the chat UI with Playwright" passed in 14m4s
(844s) where prior runs failed in 3m. But the SECOND playwright
script in the same job ("Drive Compare/Recipes/Export/Studio/
Settings") then immediately timed out at 39s with:
Locator.wait_for: Timeout 30000ms exceeded.
- waiting for locator("#new-password") to be visible
The change-password page didn't render #new-password within 30s on
the second Studio boot of the job (extra-UI script). The runner is
warmer at that point (disk cache, contended Chromium state under
--single-process) and 30s of headroom is no longer enough.
Two changes:
1. page.set_default_timeout(30_000) -> 60_000 in both
playwright_chat_ui.py and playwright_extra_ui.py. Doubles the
default for ALL operations without overcorrecting -- 60s is
still tight enough to surface real regressions.
2. All explicit `timeout = 30_000` calls (#new-password, composer
wait_for, password field on relogin, etc.) bumped to 60_000 to
match the new default. Without this, the explicit caller-passed
30s would still cap at 30s regardless of default_timeout.
This is the third stability layer for macos-14 free Mac runners:
- --single-process Chromium kills the JSON-input crash (fdf7f94)
- try/except + 90s screenshot timeout makes shoot() best-effort (1b92a8b)
- 60s wait_for default + explicit timeouts for all selectors (this)
The api-introspect job's `Dump unsloth + trl API surface` step crashed
on `import unsloth` because unsloth/_gpu_init.py:232 does an
unconditional `import triton` and the install step did not pull triton
in. The triton PyPI wheel installs cleanly on Linux x86_64 even
without CUDA (the import succeeds; runtime GPU work is what would
fail, which this job never does). Same rationale and same install
pattern as consolidated-tests-ci.yml line 192-205.
Run 25494399543 / job 74810247593 progressed past the change-password
flow + composer-mount + default_models[0] check (so commits d35bf6a
and fdf7f94's Chromium fixes are working) but then crashed on
`shoot('03b-default-model-button')` with:
playwright._impl._errors.TimeoutError:
Page.screenshot: Timeout 30000ms exceeded.
Call log:
- taking page screenshot
- waiting for fonts to load...
- fonts loaded
Page.screenshot waits for the page's webfonts to be resolved before
snapshotting. On macos-14 free runners under --single-process
Chromium, font loading for the Studio chat page (Inter / Geist Mono)
crowds the 30s default. Two changes:
1. Bump screenshot timeout to 90_000ms.
2. Wrap shoot() in try/except. Screenshots are diagnostic artifacts
uploaded for human triage; a failure to capture one should never
fail the test. The actual UI assertions live in step()/info()/
wait_for() calls, which are unaffected.
Adds animations='disabled' for deterministic captures (frozen CSS
transitions). Both playwright_chat_ui.py and playwright_extra_ui.py
get the same treatment.
First CI run on PR #5312 surfaced two issues:
1. static job: drift step found 463 files of drift (7359 / 9634 line
delta) on unslothai/notebooks @ main. That is a real upstream
backlog the notebooks-side maintainers need to address; this
workflow's role is to surface the count, not auto-fix. Mark
drift + convert as continue-on-error so the count surfaces in
the PR check UI without blocking. Drop continue-on-error once
the count returns to zero.
2. api-introspect job: pip install step did not include nbformat,
so the convert subcommand crashed with ModuleNotFoundError on
every notebook. Add nbformat + nbconvert to the install line
(matching the static job's deps) and mark its convert step
continue-on-error for the same upstream-tolerance reason.
Pre-existing failures on PR #5312 (Chat UI Tests Playwright timeout,
CodeQL job) are unrelated and out of scope for this commit.
Two new test files under tests/vllm_compat/, both CPU-only, both run
under tests/_zoo_aggressive_cuda_spoof.py so they pass on
ubuntu-latest without a GPU.
test_unsloth_zoo_imports.py import smoke for the 5 unsloth_zoo
modules the GRPO + fast_inference=True
path goes through. Strict assertions:
rl_replacements + empty_model MUST
import without pulling vllm
transitively (the use_vllm=False / no
fast_inference path on Colab without
vllm installed crashes if either of
them ever starts importing vllm).
vllm_utils + vllm_lora_request +
vllm_lora_worker_manager skip when
vllm is not on the runner; the symbol
test below covers them statically.
test_vllm_pinned_symbols.py parametrized across vLLM tags
v0.9.0, 0.9.2, 0.10.0, 0.10.2, 0.11.0,
0.12.0, 0.13.0, 0.14.0, 0.15.0. Each
cell fetches the relevant vllm source
files from github.com/vllm-project/vllm
at that tag (no pip install) and
asserts every symbol unsloth-zoo's
vllm_utils + vllm_lora_request +
vllm_lora_worker_manager hard-imports
or try/except imports is present.
Specifically catches:
- vLLM PR #30253 split of vllm.lora.models -> {lora_model,
model_manager} (unsloth-zoo commit ec186187)
- vLLM 0.14 gpu_model_runner.supports_tower_connector_lora call
(unsloth-zoo commit e3072a23)
- vLLM 0.15 LoRA manager kwarg rename (unsloth-zoo commit 2a80d543)
- LoRARequest lora_path -> lora_dir rename progression
(unsloth-zoo commits 888f79fd, e915bca1)
- UNSLOTH_VLLM_STANDBY hard-error windows on vLLM 0.10.x and 0.14.x
(unsloth-zoo commits 664e52ea, fa82dcc2) -- a sanity test asserts
these guards stay in place.
Spoof contract: pynvml is sys.modules-stubbed at module top before
any unsloth_zoo import; torch.distributed is_available / is_initialized
are pinned to safe defaults via an autouse pytest fixture; the
existing _zoo_aggressive_cuda_spoof.apply() handles the
torch.cuda surface.
Validated locally: 51 passed in 7s.
The first run on unslothai/notebooks@main surfaces 27 errors + 6
warnings, all real (peft 0.19+ / torchao floor missing in 6 nb/
notebooks the previous template fixes did not reach, 14 git+ HEAD
installs in hand-tuned exception notebooks, 6 torch/torchcodec ABI
mismatches, 1 transformers/tokenizers --no-deps drift). Mirror the
same continue-on-error pattern PR #5298 used for biome:check on the
frontend so the count surfaces in the PR check UI without forcing
the backlog to be cleaned in the same change. Drop continue-on-error
once the count hits zero.
New PR-time + scheduled workflow that walks every nb/, kaggle/, and
original_template/ notebook in unslothai/notebooks and statically
validates the install cells and user-facing code against:
- googlecolab/backend-info pip-freeze.gpu.txt (Colab oracle, refreshed
on every run; fallback snapshot committed under scripts/data/).
- PyPI metadata for transitive constraint resolution.
- Hardcoded torch/torchcodec ABI table.
- Hardcoded peft/torchao floor table.
- The live unsloth + trl API surface, introspected under
tests/_zoo_aggressive_cuda_spoof.py so the api job runs on a
GPU-less ubuntu-latest runner.
Catches the bug classes from notebooks#258 / #260 / #261 / #264 / #221
and commit 51b1462 mechanically:
R-INST-001 forbid git+ HEAD installs (notebooks#221)
R-INST-002 --no-deps + transitive constraint violation
R-INST-003 peft 0.19+ requires torchao 0.16.0+ (notebooks#258)
R-INST-004 torch <-> torchcodec ABI mismatch (notebooks#261a)
R-INST-005 --no-deps transformers + Colab tokenizers drift
(notebooks#261b / #264)
R-INST-006 forbid !!pip
R-API-003 adamw_torch_fused -> adamw_8bit hint (warning)
R-API-004 notebook references symbols outside live unsloth surface
R-EXC-001 DONT_UPDATE_EXCEPTIONS notebooks must satisfy the same
policy clauses as generated notebooks (notebooks#260)
R-DRIFT-001 update_all_notebooks.py emits no diff (commit 51b1462)
R-CONV-001 notebook_to_python.py converts every .ipynb cleanly
Files:
.github/workflows/notebooks-ci.yml PR-time + cron + dispatch
scripts/notebook_validator.py 1148 LOC, single-file
scripts/notebook_to_python.py battle-tested converter
scripts/data/colab_pip_freeze.gpu.txt fallback snapshot
scripts/data/colab_to_cpu_pin.json cu128 -> CPU wheel map
tests/notebooks/test_validator_fixtures.py 21 golden tests, all green
CPU-only by design. The api-introspect job follows the existing
consolidated-tests-ci spoof pattern (lines 309/417/536/626/826/1081/
1586/1998 of consolidated-tests-ci.yml). The smoke-install job is
opt-in via workflow_dispatch and stubs torchcodec since no CPU wheel
exists.
Validated on the live unslothai/notebooks@7af0ac0f tree: every fixture
test passes, exceptions check is silent, lint surfaces 27 errors + 6
warnings on real notebooks (mix of #258-class regressions in 6 nb/
notebooks the previous template fixes did not reach, plus 14
git+-HEAD installs in hand-tuned exception notebooks).
Two real Windows-specific issues from the latest round:
1. The prebuilt-llama-installed asserter relied on grepping
logs/install.log for "prebuilt installed and validated". That
marker is emitted by setup.ps1 (a child process spawned by
install.ps1 via `& $UnslothExe studio setup`) -- the child's
Write-Host stream does NOT come back through the parent's
Tee-Object pipeline regardless of how aggressively we redirect
(*>&1, 2>&1, etc.). The marker lands on the live GitHub Actions
console but never on disk. Switch to a filesystem-based check:
* UNSLOTH_PREBUILT_INFO.json must exist at
~/.unsloth/llama.cpp/UNSLOTH_PREBUILT_INFO.json (setup.ps1
writes this from the prebuilt response payload).
* llama-server.exe must exist at
~/.unsloth/llama.cpp/build/bin/Release/llama-server.exe.
Both must be true; their JSON content is also dumped to the CI
log for debugging.
2. install.ps1 adds $StudioHome\bin (where the unsloth.exe shim
lives) to the User PATH via a Windows registry write. That
registry update doesn't propagate to the running Git Bash
session, so the very next step (`unsloth studio reset-password`)
hits "unsloth: command not found" and exits 127. Re-export
~/.unsloth/studio/bin to $GITHUB_PATH (Windows-style via
cygpath) so every subsequent step in the same job sees it.
Both fixes are mechanical and apply to all 4 Windows workflows
(6 jobs total: 1 ui + 1 update + 1 api + 3 inference).
Anonymous calls to api.github.com share a 60-req/hour bucket per
runner IP. CI fleets exhaust this trivially -- e.g. PR 5322 run
25490821956 / job 74798111390 hit 403 on the very first
ggml-org/llama.cpp /releases?per_page=100&page=1 call, fell back
to source build, and the workflow asserter then bailed because it
expects the prebuilt path to succeed. install_llama_prebuilt.py
gave up on 403 in one shot:
raise RuntimeError(f"GitHub API returned 403 for {url}{hint}")
Now: treat 403 against api.github.com as retryable (real 403s on
other hosts -- private artefact downloads, auth failures -- stay
non-retryable). The existing download_bytes retry loop picks it
up automatically. sleep_backoff() takes an optional `exc=` and
honours the Retry-After / X-RateLimit-Reset headers so the wait
is accurate, capped at 60s (anything longer means the source
build fallback is faster than waiting). After all retries, the
existing RuntimeError surface is preserved -- callers fall back
to source build exactly as today, just less often.
Combined with passing GH_TOKEN to the install step (which the
Mac and Linux GGUF jobs on this branch already do, see e.g.
studio-inference-smoke.yml line 105), the prebuilt path is now
robust against both transient 403 blips AND sustained anonymous
rate-limit exhaustion: GH_TOKEN bumps the bucket from 60 to
5000 req/hour, and the new retry/header-honouring logic
absorbs the remaining flakes.
Run 25491698868 / job 74801076186 hit the Playwright pipeTransport
'Unexpected end of JSON input' crash on ALL THREE retry attempts
(at 11:00:52, 11:01:07, 11:01:21 — only ~15s apart). The retry-with-
Studio-reset wrapper from d35bf6a couldn't recover because the
crash hits 100% of attempts on this run, not as a rare race. Two
complementary fixes:
1. tests/studio/playwright_chat_ui.py + playwright_extra_ui.py:
pass --single-process / --no-sandbox / --disable-dev-shm-usage /
--disable-gpu to chromium.launch. --single-process is the key
one: it keeps the renderer in the browser process, eliminating
the browser↔renderer IPC pipe that was the actual crash site
(Chromium's renderer was dying mid-startup and corrupting the
pipe stream the Node driver was parsing).
2. .github/workflows/studio-mac-ui-smoke.yml: backport upstream
Playwright's try/catch around the two JSON.parse(message) sites
in driver/.../pipeTransport.js so a malformed stdout chunk
(e.g. empty buffer between two \0 delimiters) is dropped
silently instead of throwing and killing the entire Node driver.
Newer Playwright versions ship this guard upstream; we patch it
in via a python script after `playwright install chromium` so
the fix lives only in CI's Mac job. Idempotent: prints "no
matches; skipping" if upstream changes the pattern.
The retry loop from d35bf6a is kept as a third line of defense
for any residual Chromium-died-and-stayed-dead scenarios.
setup.ps1 emits the "prebuilt installed and validated" / "prebuilt
up to date and validated" markers via the `step` function, which
calls Write-Host. In PowerShell 5+, Write-Host writes to the
Information stream, NOT stdout. Plain `2>&1 | Tee-Object` only
redirects stderr -> stdout, so Information-stream output flows to
the host (visible in the GitHub Actions log) but never lands in
logs/install.log. The post-step grep asserter then fails with
"no Windows prebuilt llama.cpp marker in install.log" even though
the prebuilt was installed correctly.
Switch to `*>&1` (the wildcard "all streams" redirect) so
Tee-Object captures Information stream too. Also silence the
ProgressPreference noise that fills install.log with progress-bar
ANSI sequences.
* Dark theme refactor, right sidebar redesign, and chat UI polish
- Dark theme refactor
- Redesign right sidebar
- Further left sidebar adjustments
- Wider chat and content area; layout tweaks for chat content
- Rounded corners across elements for consistency
- Show chat message menu icons on menu-area hover, not only on message hover
- Assistant message menu icons now always visible; user messages keep on-hover
- Redesigned copy icon used consistently across chat blocks and messages
- Redesigned trash icon, applied consistently
- Unified icon sizing and style with the sidebar
- Adjusted icon colors across chat
- Fix on-hover background design for chat icons
- Fix tooltip from 'more' button staying visible after clicking elsewhere
- Adjust position and design of generation speed info text below messages
- Adjust design of token speed info popup
- Adjust sidebar scrollbar to cover recent chats only
* Recents sidebar rename, UI/theme refactor, layout and chat polish
UI & Theme:
- Dark theme refactor
- Consistent rounded corners across elements
- CSS polish and cleanup
- Remove unused logo image assets
Recents sidebar:
- Add 'more' button for options menu
- Support renaming conversations and training runs
- Confirmation dialog before deleting chats
- Add optional display_name column to training_runs (idempotent ALTER TABLE) so renaming doesn't lose model_name/dataset_name from the run config
- New PATCH /api/train/runs/{run_id} endpoint accepts { display_name: string | null }; empty/whitespace clears the override
- Sidebar shows display_name ?? model_name and exposes Rename in the row's More menu, mirroring the chat rename flow
- Cache last list response in localStorage and hydrate from it on mount, so recents paint instantly on F5 / route revisit; cached items are shape-validated and dropped if malformed
- Optimistic updates on rename and delete (apply locally + cache before background refresh)
- Visible toast on rename/delete failure instead of swallowed errors
Layout:
- Redesigned right sidebar
- Further left sidebar adjustments
- Updated chat content layout; chat and content area slightly widened
- Sidebar scrollbar covers recent chats only
Icons:
- Redesigned copy icon, unified across chat blocks and messages
- Redesigned trash icon to match
- Consistent icon sizing and style across chat and sidebar
- Adjusted icon colors across chat
- Fix icon on-hover background design
Chat messages:
- Menu icons now appear on hover over the menu area, not just the message
- Assistant message menu icons always visible; user messages keep on-hover (next/previous response stays visible for edited prompts)
- Repositioned and restyled generation speed info text below messages
- Restyled token generation speed popup
Tooltips:
- Removed tooltip on hover for previous/next assistant response icons
- Unified tooltip design across sidebars and chat
- Removed tooltip animations (also fixes related lag)
Model & Chat Template config:
- Merged Chat Template config into Model Configuration section
- Added revert-to-original for chat template
- Fix Chat Template config disappearing on page refresh until model reload
Performance & scroll:
- Removed chatbox movement animations across pages/navigation (fixes related UI lag)
- Fix scroll flicker at end of streaming when a code block is the final element
- Additional chat scroll improvements
Bug fixes:
- Fix 'more' button tooltip remaining visible after clicking elsewhere
* Remove sidebar localStorage cache and optimistic updates
Drops the localStorage hydration and optimistic rename/delete logic from the recents sidebar; reverts to fetching fresh on mount.
* Fix missing cn import in shared-composer (regression from merge)
* chore(sidebar): import sidebar deps from feature indexes
Re-export deleteChatItem / renameChatItem / useChatSidebarItems / SidebarItem / useChatSearchStore / ChatSearchDialog from @/features/chat, and removeTrainingUnloadGuard from @/features/training. Switch app-sidebar.tsx to consume them via the public feature indexes instead of deep paths, clearing the no-restricted-imports eslint errors. No behavior or UX change.
* fix(studio/frontend): reload training Recents sidebar after F5 refresh
The Recents sidebar showed empty after a hard refresh. The hook's inFlightRef dedup guard collided with React StrictMode's double-mount in dev: the second mount's fetch returned silently with no error, no retry, and no toast — leaving the sidebar empty until navigation.
Replace skip-if-busy dedup with abort-previous via a hook-level AbortController. This also fixes a latent race where a slow poll could resurrect a just-deleted row by clobbering the optimistic update.
Changes (all in use-training-history-sidebar.ts):
- fetchRuns aborts any in-flight request before starting a new one; post-await signal.aborted check drops stale responses.
- Optimistic helpers (applyRunUpdate, removeRun) abort in-flight fetches so they don't depend on caller discipline to invalidate stale data.
- Initial load gets bounded retry-with-backoff (500ms / 1.5s / 3.5s) and surfaces a sonner toast with a Retry action on final failure.
- Failure toast auto-dismisses on any successful load (initial retry, Retry click, or polling recovery).
- Polling pauses while the tab is hidden and catches up on visible, avoiding wasted requests during long training runs.
- Both effects own their teardown explicitly (abort + clear timer).
* Apply unified tooltip design and behavior across remaining pages for consistency
* UI polish: spacing, tooltip on source icons, letter spacing, smaller icons, consistent edit icon
- Adjust tiny spacing between elements around the UI for subtle polish
- Redesign tooltip on source icons for web search / tool use, consistent with the new design
- Adjust chat text letter spacing
- Smaller icon sizes
- Replace 'edit message' icon in chat with the new Rename icon used in Recents for consistency
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Adjust CSS for right sidebar
* Fix scrollbar UI compatibility across browsers
* fix: preserve chat preset settings on model load
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* fix(studio): remove duplicate chat template status field
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* chore: remove creative preset assumption
* fix(studio): align speculative decoding default
* fix(studio/chat): snap numeric param inputs to step grid
- Type a value in any param input (Temperature, Top K, Max Tokens, etc.)
now clamps to [min, max] and snaps to the slider's step grid, killing
off-grid values like 1.051234 and FP residue from slider drags.
- Branch picker chevrons share the action bar's 32px height + 10px radius
via a new .aui-branch-chevron-btn utility; hover area aligns visually
while staying narrower than the sibling icon buttons.
* fix(studio/chat): keep training-run polls converging and drop dead preset code
- Keep training-run polls converging when responses outrun the 5s interval
(don't unconditionally abort prior in-flight; skip if one is still pending,
mutation race still guarded).
- Drop dead Creative/Precise preset code paths (remove 'builtin-fixed' source
variant + unreachable branches).
* fix(studio): training-run cards show custom name + model + dataset
- Training-run cards now display custom display_name + model + dataset,
with cross-view sync on rename/delete.
- Enhance clarity of borders and colors in dark theme on export etc.
* fix(studio): match active state green to unsloth brand color
* fix(studio): preserve can_resume on training rename
* fix(studio): keep GGUF chat template override distinct
* fix(studio): treat audio input models as multimodal
* fix(studio): cancel numeric draft on Escape
* fix(studio): use default speculative mode on toggle
* fix(studio): detect GGUF audio VLM input models
* fix(studio): address final PR review findings
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* fix(studio): refresh sidebar/history when a new training run starts so it appears without a manual reload
* fix: API and svg
* fix(studio/sidebar): align run rename dirty check with displayed baseline
* fix(studio/sidebar): use leading-tight on account block to prevent descender clipping with truncate
---------
Co-authored-by: sneakr <hauzin@hotmail.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Roland Tannous <115670425+rolandtannous@users.noreply.github.com>
Co-authored-by: shine1i <wasimysdev@gmail.com>
Belt-and-suspenders for the --no-deps install of no-torch-runtime.txt:
add a workflow step in every Windows job that runs
pip install --upgrade typer pydantic huggingface_hub
inside the Studio venv after install.ps1 finishes. install.ps1 itself
keeps --no-deps so torch never lands transitively, but typer +
pydantic + huggingface_hub don't depend on torch and absolutely need
their full runtime dep trees to import. Pinning the exact transitive
list in no-torch-runtime.txt is fragile (each minor version of typer
or pydantic adds another package -- click, then annotated-doc, then
pydantic-core, then typing-inspection, etc.). The follow-up
pip install --upgrade is idempotent (no-op when everything's already
there) and pulls in any missing module in one step.
Also pin typing-inspection in no-torch-runtime.txt directly so the
Linux/Mac --no-deps path picks it up the next time a fresh runner
image is provisioned.
Whack-a-mole on the --no-deps install: after typer's deps (click,
shellingham, annotated-doc, rich, etc.) the next module hit is
pydantic_core, which lives in a separate wheel from pydantic and so
is NOT installed when `pydantic` itself is installed --no-deps.
Pin pydantic-core and annotated-types (pydantic's other dep tree
member) so the import chain works on a fresh windows-latest venv.
Two distinct Mac UI Chat failures captured in PR 5312's CI:
1. /api/inference/load 500 with FileNotFoundError on config.json for
unsloth/gemma-3-270m-it-GGUF (a GGUF-only repo). Run 25487410091.
Root cause: detect_gguf_model_remote in
studio/backend/utils/models/model_config.py had a single
hf_model_info call with no retry. On a transient HF Hub flake
it returned None silently, the route at routes/inference.py:592
treated the repo as non-GGUF, and dispatched to the MLX
orchestrator. The orchestrator's _build_model_config re-ran
from_identifier in the subprocess (this time succeeding,
logging "Detected remote GGUF") but then handed an is_gguf=True
ModelConfig to MLXInferenceBackend.load_model, which ignored
is_gguf and called FastMLXModel.from_pretrained →
mlx_lm.utils.load_model → opened a non-existent config.json on
the GGUF-only repo. Fix:
a) detect_gguf_model_remote retries up to 3 times with 1/2/4s
backoff, bypassing retry on RepositoryNotFoundError /
GatedRepoError / RevisionNotFoundError / EntryNotFoundError
(those are permanent).
b) MLXInferenceBackend.load_model now raises a clear
RuntimeError if config.is_gguf=True, instead of letting
mlx_lm surface a cryptic 'config.json does not exist'.
2. Playwright pipeTransport.js 'Unexpected end of JSON input' on
macos-14 free runners. Runs 25489049059 + 25489429306. Chromium
browser process dies mid-test → driver Node process can't parse
the truncated JSON-RPC line and exits. Hits ~50% of runs (well
above acceptable flake). Fix: retry the chat-UI step up to 3
times, FULLY resetting Studio (kill, reset-password, reboot,
/api/health wait, re-export STUDIO_OLD/NEW/NEW2_PW) between
attempts so the change-password flow finds a fresh bootstrap on
each retry. Same retry shape on the extra-UI step. Real
assertion / timeout failures don't match the JSON-input pattern
so they bypass retry and surface immediately. Updated the
install-step comment to drop the now-incorrect '1.55-1.57 ship a
Node 22 driver' claim — all 1.55-1.58 Mac drivers are Node 24,
the racy crash is in pipeTransport itself.
After the previous click+shellingham pin, the next missing module was
annotated-doc, then rich, then its own subdeps. Pin the entire typer
runtime dep tree so unsloth studio setup boots cleanly on a fresh
windows-latest venv (and any other --no-deps install path).
Windows defaults to cp1252 ("charmap"); the hf-hub CLI prints a
success checkmark "✓" (U+2713) and the bare hf download in the
"Prime HF_HOME" step dies with:
Error: Invalid value. 'charmap' codec can't encode character
'✓' in position 5: character maps to <undefined>
Set PYTHONIOENCODING=utf-8 and PYTHONUTF8=1 at the job level for all
four Windows Studio workflows. Same env vars work on Linux/Mac as
no-ops, so we don't need OS-conditional handling.
install.sh / install.ps1 install no-torch-runtime.txt with --no-deps,
which means typer's runtime dependencies (click, shellingham) never
land. On Linux/Mac CI click happens to be cached transitively from
previous jobs in the runner image; on a fresh windows-latest venv
unsloth studio setup fails the very first time it runs:
Traceback (most recent call last):
File ".../unsloth/__main__.py", line 4, in <module>
from unsloth_cli import app
File ".../unsloth_cli/__init__.py", line 4, in <module>
import typer
File ".../typer/__init__.py", line 7, in <module>
from click.exceptions import Abort as Abort
ModuleNotFoundError: No module named 'click'
Pin click and shellingham explicitly so the no-torch path works on
every fresh venv, on every OS.
Adds four Windows counterparts to the existing Mac Studio jobs, all on
the free windows-latest runner (4 vCPU / 16 GB / 14 GB SSD; no premium
SKU). Mirrors the Mac coverage 1:1 in name and assertion shape so the
PR-status grid reads "Mac Studio * = Windows Studio *":
studio-windows-ui-smoke.yml -> "Windows Studio UI CI"
studio-windows-inference-smoke.yml -> "Windows Studio GGUF CI" (3 jobs)
studio-windows-update-smoke.yml -> "Windows Studio Update CI"
studio-windows-api-smoke.yml -> "Windows Studio API CI"
Key Windows differences vs the Mac mirrors:
* runs-on: windows-latest (free public runner)
* defaults.run.shell: bash so curl / jq / heredoc steps go through
Git Bash (windows-latest's default shell is pwsh)
* Install step uses pwsh + ./install.ps1 --local --no-torch (NOT
bash install.sh; install.sh has no Windows branch and would hit
apt-get / brew calls). install.ps1 is Studio's documented Windows
installer and is exercised by release-desktop.yml today.
* Asserter looks for bin-win-cpu-x64 (the prebuilt that
windows-latest, no GPU, hits via studio/install_llama_prebuilt.py
line 1272). Source-build fallback is rejected as a Studio bug.
* setup-python: drop cache:'pip' across all four (install.ps1 +
setup.ps1 use uv; setup-python's post-step otherwise fatal-errors
with "Cache folder path is retrieved for pip but doesn't exist").
* api-smoke: do NOT pin STUDIO_AUTH_DIR (Mac mirror hardcodes
/Users/runner/...). studio_api_smoke.py defaults to
Path.home()/'.unsloth'/'studio'/'auth' which resolves correctly
on every OS.
* inference-smoke: drop the Linux-only `ss -tln` diagnostic line.
No code changes to install.ps1, setup.ps1, install_llama_prebuilt.py,
or unsloth_cli/commands/studio.py -- Windows is already fully wired
in those (~30 host.is_windows branches in the prebuilt installer +
three sys.platform=='win32' branches in the Studio CLI).
Also fixes the Linux Chat UI Tests "extra turn" timeout (run
25487410101 / job 74786523982). The send_and_wait predicate used
non-empty assistant bubble count vs a baseline. When gemma-3-270m
emitted an empty turn (legitimate model output), the empty bubble
counted toward total but NOT toward the non-empty baseline, and the
next turn's wait expected nonempty >= baseline + 1 forever -- never
satisfied. Refactor:
* Snapshot TOTAL bubble count before send (proves new placeholder
rendered, regardless of content).
* Wait for Send-button-attached AND Stop-button-detached as the
"previous turn finished" signal.
* Treat empty bubbles as legitimate model output, not test failure.
* Add page.on('response') listener for /v1/chat/completions and
log status distribution + 4xx count after the 5-turn loop, so a
flake is debuggable from the CI log without artifact spelunking.
* tests/studio/install: parallel UNSLOTH_STUDIO_HOME smoke test
Adds tests/studio/install/smoke_test_parallel_studio_home.py to lock in
the install-time and runtime isolation guarantees added by #5190.
The runner spawns N concurrent install.sh --local --no-torch jobs, each
with its own UNSLOTH_STUDIO_HOME and a redirected HOME, then launches N
backends on dynamically allocated ports and cross-checks every install
against its running process. Asserts:
install-time
- all N installs exit 0
- per-install bin / share / llama.cpp / unsloth_studio venv tree
- shim symlink resolves into its own venv, no cross-resolution
- share/studio_install_id is unique across the N installs
- share/studio.conf exports UNSLOTH_EXE / UNSLOTH_STUDIO_HOME /
UNSLOTH_LLAMA_CPP_PATH all pointing inside the install
- share/launch-studio.sh has @@DATA_DIR@@ substituted to its own
share/ at install time
- the redirected HOME stays clean: no rc-file append, no
.desktop file, no Studio.app stub, no shared marker
runtime
- /api/health returns 200 with status healthy and chat_only true
- /api/health.studio_root_id matches share/studio_install_id
(runtime resolver agrees with install-time write)
- studio_root_id values are pairwise distinct
- GET / and GET /api/chat return 200 on each backend
- /proc/PID/exe is the install's own venv python
Standalone smoke runner, not pytest collected. Default --n 4 finishes
in about 60 seconds on a warm uv cache; artifacts are removed on PASS
unless --keep is passed and kept on FAIL or ERROR for inspection.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* tests/studio/install: portability + log fd cleanup in parallel smoke
Two cleanups on the parallel UNSLOTH_STUDIO_HOME smoke runner:
- Skip the /proc/PID/exe runtime cross-resolution check on platforms
without /proc (macOS, BSD, Windows). install.sh supports macOS, so
the smoke should not hard-error there. The install-time symlink,
studio.conf and launch-studio.sh assertions already pin the venv
python target statically; the proc check stays as a Linux-only
redundant cross-resolution catch and now returns None cleanly on
other platforms instead of raising.
- Wrap the per-backend log file in a with-statement so its parent fd
is released deterministically at function return. The child still
holds its own dup'd fd via Popen, so logging continues unchanged.
The prior code relied on local-scope GC and was fine in CPython,
but the with form makes the intent explicit.
Smoke still passes locally: 4 parallel installs in 42s, 4 backends
healthy in 5s, all install + runtime invariants hold.
* tests/studio/install: pin UNSLOTH_STUDIO_HOME on backend launch
The launch step copied os.environ unchanged except for HOME. If the
parent shell already exports UNSLOTH_STUDIO_HOME or STUDIO_HOME (for
example, when the developer is sourcing studio.conf from an existing
install), every backend inherits it and the Studio resolver prioritises
those env vars over the per-label sys.prefix inference. The runtime
invariant block then reports the caller's install_id on every port
instead of the per-label one, and the test fails spuriously rather
than testing the right roots.
Pin UNSLOTH_STUDIO_HOME to the per-label studio_home and pop the
STUDIO_HOME alias for each launch, mirroring what _run_one_install
already does for the install step.
Verified by running the smoke with UNSLOTH_STUDIO_HOME=/nonexistent
and STUDIO_HOME=/also-bogus exported in the parent env: PASS, all four
backends report their own install_id rather than the parent value.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Mac UI run 25487129268 failed at composer.wait_for() with:
SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at Immediate.<anonymous>
...playwright/driver/package/lib/server/pipeTransport.js:78:42
Node.js v24.14.1
Playwright 1.59 ships a bundled Node 24 driver whose pipeTransport.js
calls JSON.parse on every line received from the Chromium child
process, including empty/truncated lines. On the macos-14 free runner
(slow disk + slow process spawn) the Chromium launch sometimes emits
an empty stdout line during init, and Node 24's stricter parser turns
that into a fatal SyntaxError that takes the whole driver down.
Pin to playwright>=1.55,<1.58 -- those versions ship a Node 22 driver
that tolerates the empty-line race. Linux uses 1.59 fine because the
ubuntu-latest runner is faster and doesn't hit the race; only Mac
needs the pin.
The previous matrix run on commit 7855571a tripped on 7 model_types
not in my initial list (which I built from transformers 4.57.6).
Latest 5.x ships more model_types; same regex/source-rewriter
failure modes:
audioflamingo3 emitted file: unterminated string literal
colmodernvbert string index out of range
gemma4_assistant string index out of range
musicflamingo emitted file: unterminated string literal
sam3_lite_text name 'Sam3LiteTextLayerScaledResidual' is not defined
voxtral emitted file: unterminated string literal
voxtral_realtime emitted file: unterminated string literal
Added each to KNOWN_BROKEN_COMPILE under the appropriate failure
category (string-index, unterminated-string, undefined-name). Same
contract as before -- new failures NOT in this list still fail the
cell. The unterminated-string family (4 of 7) is a NEW failure
category; documented as Category B-2.
* fix: API settings overflow with long Colab URLs
* fix: gentle wrapping for API usage snippets
---------
Co-authored-by: Roland Tannous <115670425+rolandtannous@users.noreply.github.com>
New step "MoE per-family coverage + GRPO patches + grouped_gemm AST"
that hardens the matrix against the recurring MoE bug class behind
unslothai/unsloth-zoo#624 / #612 / #607 / #601 and unslothai/unsloth
#4934 / #3598. Five clusters of pytest cases inside one shim:
1. Per-MoE-family side-effect contract (8 parametrized cases):
For each `patch_*_moe` in unsloth_zoo.temporary_patches.{qwen3_moe,
qwen3_5_moe, qwen3_next_moe, qwen3_vl_moe, gemma4_moe, glm4_moe,
deepseek_v3_moe, gpt_oss}, look up the transformers target classes,
skip when none import on this matrix cell, run the patch fn, and
assert at least one importable target now carries an unsloth
"patched" marker. Accepts five marker conventions used across the
codebase (_unsloth_already_patched, _unsloth_lora_patched,
_unsloth_lora_extractor_fn, _original_<modeling_tail>_<cls>_forward,
plain _original_forward). Surfaces silent early-returns (PR #612)
that escape the registration-coverage test.
gpt_oss specifically reads UNSLOTH_MODEL_NAME and only runs on
transformers >= 5; the shim sets the env var via monkeypatch and
skips on the 4.57.6 cell with a documented reason.
2. PR #4934 (TRL 1.0 GRPO disable_gradient_checkpointing): rebinding
contract. After patch_trl_disable_gradient_checkpointing(), the
no-op decorated function MUST be the symbol on
trl.models.utils AND every trl.* module that imported it by
reference. Skips on TRL < 1.0 (no symbol present).
3. PR #3598 (gradient_accumulation): patch_gradient_accumulation_fix
on a vanilla transformers.Trainer must run cleanly without raising
AND be idempotent. Catches future double-scale or import-injection
regressions in the source rewriter.
4. unsloth/kernels/moe/grouped_gemm AST smoke: walks every .py under
the directory (12 files) and asserts ast.parse succeeds. Triton
kernels are GPU-only at runtime, but a syntax error in source
surfaces as ImportError on every install. Also sanity-checks the
directory layout (interface.py, kernels/forward.py,
kernels/backward.py, reference/moe_block.py, reference/moe_ops.py
must exist).
Local verification on host TRL 0.25.1 + transformers 4.57.6: 4 pass
(qwen3_moe, qwen3_vl_moe, GRPO disable-GC, grad-accum, grouped_gemm
AST), 7 skip legitimately (qwen3_5/qwen3_next/gemma4/glm4/deepseek/
gpt_oss absent or version-gated). Wall-time ~10s on host; budget
~30-60s per matrix cell.
Two extensions to the strict-mode matrix:
1. Compiler full-model-sweep. The previous step parametrized
`unsloth_compile_transformers` over [llama, qwen3, gemma3] only.
Replace with `pkgutil.iter_modules(transformers.models.*)` walk so
every model_type the matrix's transformers ships gets exercised
(~383 packages on transformers 4.57.6, similar on latest). Local
verification: 362 / 383 compile cleanly in 108s wall (~0.31s/model
mean). 21 model_types currently break the rewriter; they are
listed in KNOWN_BROKEN_COMPILE in the shim, split by failure
category for follow-up unsloth-zoo PRs:
A. `string index out of range` (6): colpali, colqwen2, dpr,
rag, shieldgemma2, timm_backbone.
B. emit invalid Python (8): clvp, electra, falcon_mamba, gpt2,
imagegpt, mamba, tapas, xlstm.
C. emit unclosed paren (2): kosmos2, kosmos2_5.
D. attribute error on imports (4): auto, bit, regnet, resnet.
E. undefined name in emitted file (1): perceiver.
New failures on any OTHER model_type fail the cell. Floor of >=200
ok models guards against transformers-induced wholesale regression.
2. Dynamic TRL trainer + experimental coverage. The previous discovery
sweep only counted *Trainer / *Config discovery; it did not verify
unsloth ACTUALLY patches what it discovers. Two new pytest cases
in the same shim:
- `test_unsloth_patches_every_canonical_trainer_in_this_trl_version`:
enumerate canonical trainers via filesystem walk, run
patch_trl_rl_trainers(), assert each is Unsloth-prefixed.
Floor matches cohort sizes (18 / 15 / 6 trainers across
0.22-0.23 / 0.24-0.28 / 0.29-1.x).
- `test_unsloth_patches_experimental_trainers_via_thin_wrappers`:
walk `trl/experimental/*` AST for *Trainer classes, verify
unsloth's MRO-walk fallback (rl.py:677-702) reaches them.
TRL 0.29+ moved 9 trainers (bco/cpo/gkd/nash_md/online_dpo/
orpo/ppo/prm/xpo) to trl.experimental; we want the matrix to
confirm patching reaches that surface, not just the canonical
6.
Wall-time per cell: compile sweep ~2-3 min warm; trainer sweep ~30-60s.
Total cell budget remains under 35 min including the existing llama.cpp
build.
The Tool calling job was getting cancelled at 16-17 minutes because
the macos-14 free runner generates ~10 tok/s on Qwen3.5-2B Q4_K_XL,
and the four SSE streams x 600 max_tokens add up to >12 minutes of
streaming alone -- with the model frequently entering a degenerate
output state at temperature=0.2 that only terminates at max_tokens.
Per-call adjustments:
- function calling tool: 600 -> 300 max_tokens, +180s timeout
- python tool SSE: 600 -> 256 max_tokens, +180s timeout
- terminal tool SSE: 600 -> 256 max_tokens, +180s timeout
- web_search SSE: 400 -> 200 max_tokens, +180s timeout
- thinking on/off: 300 -> 150 max_tokens, +180s timeout
- json_object response: 600 -> 200 max_tokens, +240s timeout
- plain capital-of-france: 400 -> 150 max_tokens, +240s timeout
Total worst-case streaming time drops from ~12 min to ~5 min,
leaving room for the model-load wait and SSE setup overhead.
unsloth-zoo#630 narrowed the MoE-coverage test canary to the
`_unsloth_already_patched=True` marker. The T 4.57.6 cell of the
strict-mode consolidated matrix should now skip rather than fire on a
3D-pattern false positive. Re-running to confirm.
