This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.
Some bugs crash. Some bugs corrupt. The one that taught me the most did neither — it reported success while doing absolutely nothing, and it did it during a launch gate.
The setup
Launch night for a long-running engine on a Windows box. Part of the pre-launch checklist: a cleanup sweep that finds and stops every stray process belonging to the project — old workers, orphaned watchers, half-dead servers from earlier test runs. You don't want six zombie processes fighting the fresh launch for ports and file locks.
The sweep filtered processes by command line, PowerShell-style:
Get-CimInstance Win32_Process |
Where-Object { $_.CommandLine -like '*C:\\Users\\me\\project\\*' } |
ForEach-Object { Stop-Process -Id $_.ProcessId -Force }
It ran. It printed nothing scary. Exit code zero. "All clean." We moved on.
Seven target processes were still alive.
The bug
Look at the pattern: '*C:\\Users\\me\\project\\*'.
I doubled the backslashes — pure muscle memory from every other language I touch, where \\ is an escaped backslash. But in a single-quoted PowerShell string there is no escaping. Those are literal double backslashes. And a live process's command line contains single backslashes: C:\Users\me\project\worker.mjs.
So the -like comparison was asking: does any command line contain a double backslash path? Answer, forever: no. Zero matches. And here's the cruel part — in this pipeline, zero matches is indistinguishable from a perfectly clean system. The filter's failure mode and its success mode produce identical output: silence.
The sweep couldn't fail loudly. It could only fail politely.
The catch
It surfaced at the final launch gate, which has one rule: exercise every piece against real state, not the happy path. The gate re-checked the process table directly — not through the sweep, through fresh eyes — and there they were: seven survivors the "successful" cleanup never touched, one already squatting on a port the launch needed.
The diff that fixed it is almost insultingly small:
# before — wildcard pattern, escaped-backslash reflex, matches nothing, forever
$_.CommandLine -like '*C:\\Users\\me\\project\\*'
# after — .NET string containment, no wildcard/escape semantics at all
$_.CommandLine.Contains('C:\Users\me\project\')
.Contains() does dumb literal substring matching — no wildcard grammar, no escape rules, nothing to get subtly wrong between languages.
The real fix wasn't the one-liner
The one-liner repaired the sweep. The lesson repaired the process, and it's the thing I'd tattoo on every ops script I own:
A filter that cannot fail loudly must be negative-controlled before its verdict counts.
Concretely: before trusting any find-and-act sweep, feed it a known positive — spawn one deliberate target process and demand the sweep finds it. If it can't catch the fish you planted, its "empty net" means nothing about the lake. We wired exactly that into the sweep's own self-test: it now refuses to report "clean" unless it has proven, that run, that it can see a target.
Same doctrine, wider than PowerShell: a grep that returns nothing, a linter that finds no issues, a security scan that comes back green, a test suite filtered to zero tests — every one of those is either good news or a broken instrument, and the output alone cannot tell you which. Only a planted positive can.
What I carry from it
- "No results" is a claim, not a fact — and it's the one claim your tooling will never volunteer to disprove.
- Cross-language reflexes are silent killers: my
\\habit was correct almost everywhere else, which is exactly why I never looked at it. - Verification that re-checks reality through an independent path (the process table itself, not the sweep's report) is what actually caught this. The sweep grading its own homework had a 100% pass rate the whole time.
The system launched clean that night — after the gate did its job. The sweep had reported clean before doing its job. The difference between those two sentences is the whole discipline.
Part of The Organism Files — an ongoing record of building a verification-first AI partnership from scratch.
