A gate that never runs isn't a gate

A review pass over Greenhouse’s CI pipeline turned up the kind of findings that are individually small but collectively worrying: a list of 24 Tauri commands hand-duplicated between the TypeScript IPC boundary and the Rust handler registration, with nothing catching drift between them. A real-Chromium color-contrast test that existed in the repo but ran nowhere in CI. No dependency auditing at all. A release workflow that built and uploaded a .dmg without ever opening it. The follow-up issue was simple: work through the list.

Most of it went the way you’d expect. The IPC contract test is a few lines of regex diffing two files against each other. The release smoke test mounts the .dmg, checks the code signature, launches the app with a throwaway vault path so it skips the onboarding dialog, and confirms it’s still alive five seconds later. Straightforward stuff.

The dependency audit is where it got interesting. The issue named a specific advisory to ignore, GHSA-wrw7-89jp-8q8g in the glib crate. I looked it up, mapped it to RUSTSEC-2024-0429, wrote the ignore entry, ran cargo deny check advisories to confirm it worked, and got a clean pass with a warning: “advisory was not encountered.” The crate the issue was worried about isn’t even in the current dependency graph anymore. But the real check turned up eighteen other advisories I hadn’t gone looking for. Two of them were actual vulnerabilities, not just staleness warnings, quadratic-time and unbounded-allocation bugs in quick-xml, pulled in transitively through the plist crate Tauri uses for macOS bundling. Both fixed for free with a Cargo.lock-only version bump, no manifest change needed. The other sixteen were unmaintained advisories against Tauri’s own Linux GTK3 bindings and an old Unicode dependency, nothing I can fix from this repo, so those got individually documented ignores with a reason each instead of one blanket exception.

The part that stuck with me most, though, was the contrast gate itself, the exact thing the issue was about: a check that exists but doesn’t run. I wired npm run a11y:contrast into CI, ran it locally first to make sure it’d actually pass, and it didn’t. Two tests failed. Not flaky, not environmental, just wrong. A prior commit had added a getConfigStages() call to the dashboard and the onboarding wizard so stage names could be resolved from live config instead of guessed from a raw ID. The jsdom-based tests that run in CI already had mocks for that call. The real-Chromium contrast test, which runs nowhere, didn’t. So one component crashed trying to .map() over a null config list, and the other silently disabled its own “Next” button forever because the promise it awaited resolved to null instead of an empty array. Nobody noticed, because there was no CI step to notice with. That’s the whole argument for this issue in one bug: a gate that exists in the repo but doesn’t run anywhere is functionally identical to no gate at all, except it also gives you false confidence that one exists.

Small bonus find along the way: the same test file had no headless setting on its Playwright config, so every local run of that test had been popping open a real, visible Chromium window and stealing focus. Nobody had run it enough times in a row to find that annoying until this week.

Six of seven pieces landed cleanly from research and local verification alone. The seventh, wiring Chromium into the CI runner, needed one fact the agent working this couldn’t get from inside the repo: whether the self-hosted Linux runner already had the OS-level shared libraries a headless browser needs. I could answer that one directly, since I run the host: the same machine already runs headless Chromium for a different site’s accessibility checks, so the fix was just fetching the browser binary, no new system packages required. Worth remembering that some questions really do need the person with SSH access, and it’s faster to ask than to guess and find out from a red CI run.