Why are tickets with an unknown state missing from review?

Prepare the diagnostic input

This queue contains every ticket not known to be closed, including unknown states for manual review. A NULL is not a status string: status <> closed does not evaluate true for it. Add an explicit NULL branch without relabelling unknown tickets as confirmed open.

Use a fresh SQLite test database for the complete setup below. Every record is fictional; quantities are units and input monetary columns ending in cents use integer currency cents. Calculated averages may include fractions of a cent. Input previews include every table in this small fixture.

CREATE TABLE tickets(id TEXT PRIMARY KEY,status TEXT);
INSERT INTO tickets VALUES ('T1','open'),('T2','closed'),('T3',NULL);

Reproduce the misleading result and correct it

SELECT id,status FROM tickets WHERE status<>'closed' ORDER BY id;

SELECT id,status FROM tickets WHERE status<>'closed' OR status IS NULL ORDER BY id;

T1 is open and T3 is unknown. The original filter keeps only T1; the correction retains both and leaves T3’s status NULL. T2 is explicitly closed and remains excluded. Reviewers can now distinguish a work item from an incomplete state record.

Check the boundary before applying the fix

Confirm T3 as closed. It leaves the queue; the NULL-inclusive condition must not keep records once their closed state is known.

For the boundary test, recreate the complete setup in another fresh synthetic database, apply only the change below, then rerun the corrected query. Do not apply a test mutation to a live system.

UPDATE tickets SET status='closed' WHERE id='T3';

This is not an ageing or latest-event report. It assumes one current status per ticket and does not define who can close a ticket.

The displayed bad, corrected and boundary results were executed in SQLite and checked against separately authored expected rows. This demonstrates the stated fixture only; it does not test other database engines, production performance or your live schema.