The pre-merge lane compiles no Metal TU: `metal_mlx_provider.mm` is built only by the tag-triggered `release.yml`, so a seam refactor breaks it silently until a release is cut

[localai-bot]

src/vt/metal/metal_mlx_provider.mm is compiled by nothing that runs before a merge, so a refactor of the vt::OpProvider seam it depends on breaks it silently and the breakage surfaces at release-cut time. #1584 is the first demonstration: its edit to MlxFallback landed unbuilt and unrun, and #1692 records that.

One correction to #1692 first, because it changes what is owed. #1692 states the file is "compiled by NO job in this repository". That is not accurate. .github/workflows/release.yml:347 mlx_arm64 runs on macos-15, pip install 'mlx==0.32.0', and calls scripts/build-macos-release.sh macos-arm64-metal-mlx preview ... "$mlx_root" 0.32.0 ..., which configures -DVLLM_CPP_MLX=ON and compiles the file for real, against real MLX, on real Apple hardware.

The defect is the trigger, not the absence:

on:
  workflow_dispatch: {}
  push:
    tags: ['v*']

release.yml fires on a v* tag or a manual dispatch. It never runs on a pull request and never on a push to main. .github/workflows/ci.yml — the pre-merge lane — has no macOS runner at all: every one of its 20 runs-on lines is ubuntu-latest, ubuntu-24.04-arm or windows-2022. So the only build of this file happens after the change has landed, and only when somebody cuts a release. A broken .mm is discovered as a blocked release rather than as a red check.

What can be done cheaply, and what cannot.

metal_mlx_provider.mm is the one Metal TU that is plain C++ wearing an ObjC++ extension. It contains zero Objective-C constructs: no message send, no @-keyword, no id<...>, no NS/MTL type outside comments. Its two #imports are <Foundation/Foundation.h> and <Metal/Metal.h>, and it uses nothing from either — the Metal handles reach it as void*, because metal_buffers.h and metal_context.h are deliberately plain C++ (metal_context.h:22: "This header is deliberately PLAIN C++ (no Objective-C types)"). The other three (metal_ops.mm, metal_backend.mm, metal_context.mm) carry real ObjC and are not covered by this.

That makes a compile-only bit-rot guard possible on Linux, in the shape this tree already uses twice: vllm_rocm_platform_syntax_check (CMakeLists.txt:1665, an OBJECT library that is never linked, whose comment states this exact argument) and vllm_music3_depth_stage_ab_{before,after} (CMakeLists.txt:2546).

Scope, stated as a limit rather than a claim. Such a target must stub the two Apple framework headers (trivially — nothing is used from them) and the six MLX public headers. It therefore proves that the file compiles against the real vt:: seam headers, and proves nothing about the MLX API, which only mlx_arm64 can. That is the whole defect being closed and no more of it: the #1584 break was a change to our header, not to MLX.

Owed after such a change, and not discharged by it: the CUDA and Metal runtime arms of #1692 (a GPU and a Mac), and the MLX API surface (release-time only).

[localai-bot]

Correction to my own count in the body, measured rather than eyeballed: .github/workflows/ci.yml has 17 runs-on lines, not 20 — ubuntu-latest x14, ubuntu-24.04-arm x1, windows-2022 x2. The conclusion is unchanged and is what the number was there to support: zero Apple runners.

Worth naming the near-miss, because a reader checking this will grep for it: ci.yml does contain the string macos, exactly once, at :199 — python3 tests/scripts/test_release_macos_metadata.py. That is a metadata test over the release manifest. It compiles no Metal TU and would not notice a broken one.

[localai-bot]

Closed knowingly on decision C, with the trade stated rather than glossed.

What landed — 1791ec90e (PR #1792), building on 15298f033:

All four Metal TUs are now compiled before a release is cut — metal_backend.mm, metal_context.mm, metal_ops.mm and metal_mlx_provider.mm — on macos-15 against the real SDK, AppleClang and the real mlx==0.32.0 wheel. That discharges both owed items from #1692's report: O3 (the three ungated ObjC TUs) and O2 (MLX API drift), the latter being something no stub approach could ever reach.

Proved on the lane itself, not by reasoning — four dispatched runs, one probe branch per file, read at job level:

break	macos-metal-mlx
none	success 5m03s, all four .mm.o compiled
RegisterBackend(	failure — metal_backend.mm:141:5
VT_CHECK(	failure — metal_context.mm:44:5
RegisterOp(	failure — metal_ops.mm:1092:5

Each red fails at the compile step and skips the object-existence step, so the compiler produced the failure, not the assertion. Before the gate, the same three breaks applied together left cmake --build at rc 0 with zero error: lines, never mentioning the files — the defect this closes.

The trade, in plain terms. This title asks for the pre-merge lane; what shipped is post-merge. The job triggers on push and schedule, never on a pull request (completed/skipped, 0 s, runner_name: null). A pre-merge macOS job was costed and declined: a macos-15 runner took 45 and 50 minutes to allocate during this work, so it would have cost that in wall time on every PR on top of ~10x the runner price. The exposure window goes from 955 commits (the gap since the last release build) to one.

Two findings worth keeping:

• The expected first red did not happen. After 955 commits without a macOS build, all four TUs still compiled. The drift was exposure, not yet a break.
• The gate is wired against becoming a mute switch: it asserts all four .mm.o objects exist and joins baseline-summary's needs: with EXPECTED_JOBS pinned 11→12, mutation-checked so dropping it reds.

Still open and unaffected: #1692, for runtime execution of the CUDA and Metal arms — that needs a Mac and a CUDA device and cannot be faked. src/vt/metal/stubs/README.md's limit is untouched and still accurate for the wave-1 Linux target, which remains the only Metal signal a PR gets.