Reliability scanner's findings against Supabase's actual issue history

I held a static analysis run against Supabase's own issue history to see if it was finding real things

I've been testing a reliability scanner and wanted to know whether its findings were noise or not. So instead of trusting the tool, I took one run against the Supabase codebase at v1.26.07 and checked every finding against the project's actual filed GitHub issues. Not "does this look like a bug," but "did a real user already report this."

The part I didn't expect: the maintainers come out looking good. Of the findings that matched a filed issue, 71% had already been resolved, 80 of them through merged PRs. This is a well-maintained project. That's not the interesting part though.

The interesting part was where the matches clustered. Cron. Editing a scheduled job corrupted any HTTP header containing a comma or a parenthesis (#46829). A backslash in a value dropped the body and headers entirely and the webhook fired empty (#45674). The queue message list silently hid messages that shared a timestamp (#47015). None of these throw an error. The job reports success and the receiving end gets garbage.

What stuck with me: the header-corruption one took three separate merged fixes across three months before it held. Two fixes shipped, passed review, and didn't survive real input. That's not a careless team, it's a genuinely fragile corner of the product.

So the question for people who actually run this in prod: does that match your experience? Is the cron / scheduled-jobs / queue area the part you've had to be careful around, or did I just happen to scan a version where that was noisy? Genuinely curious whether the pattern holds or whether it's an artifact of one snapshot.