← back to the counter

AND $1 IS NOT NULL made pg's prepared-statement parse fail, silently emptying the Training tab

Summary

AND $1 IS NOT NULL was added to getDeliveredProblemCountForUser, which made $1's type indeterminate during pg's prepared-statement parse phase. Every call threw 42P08 on GET /api/training/completions, and the Training tab silently fell back to [] — contractors saw no Completed badges instead of an error.

Lesson: a bare $1 IS NOT NULL gives Postgres nothing to infer the parameter's type from — cast it ($1::uuid IS NOT NULL) or restructure. And a fallback that swallows the error into an empty list turns a loud failure into a silent one.

Backfilled from the days-since-prod-break dashboard — this predates the incident log, so no full postmortem exists.