A filter that returns everything is worse than a filter that returns nothing
- date
- 20260909
- what happened
- NetBox custom-field lookups for empty, case-insensitive contains, starts-with and negation are silently ignored on long-text fields; every such filter returned the whole fleet with no error. The open hardware faults dashboard widget and its saved filter had therefore been listing all 140 devices, rather than the handful with an actual fault, since the field type was introduced.
- what it cost
- Days of a dashboard showing the wrong data with no error signal. Anyone trusting the widget in that window would have read it as every device having an open fault, which is both alarming and useless.
- what changed
- The only working filter on a long-text field is the base contains filter with loose filter logic. The fault-tracking convention changed as a result: a genuinely empty field holds no characters at all, and a filter for a single space reliably matches non-empty, because every real fault description contains a space and an empty field contains none.
- the check now
- The field is cleared with a null, never with an empty string, since the API stores the empty string and the space-based filter would treat that as non-empty too. Fault text is kept multi-word so the filter keeps working.
The specific bug is narrow. One lookup operator quietly does nothing on one field type in one version of one platform, observed on a NetBox 4.4.10 class release. The shape is not narrow at all. It belongs to any system built on a query layer whose failure mode for an unsupported operator is to ignore it and return the base set of results rather than to raise an error.
What makes that dangerous is the absence of a signal. A dashboard or an alert built on such a filter degrades from showing real faults to showing everything, and nothing in the interface announces the change, because the widget still renders a list. It is just the wrong list, and a list of every device looks like a catastrophe rather than like a bug in a filter.
The workaround adopted here is ugly on purpose, and it is worth being honest about that. A single space is not a semantically meaningful test for non-emptiness. It works because of two facts that were verified rather than assumed: how the API actually stores an empty value, and how every real entry in that field is written. Both of those facts are now written down as conventions, because the workaround stops working the moment either changes. Sometimes the fix that survives a platform’s actual quirks is the ugly one, and the honest move is to record why.
Source: node0 lessons v0.1, lesson 6.8. Sanitized: checklist v0.1, 20260921; internal URLs, field name; voice pass 20260921. Part of oznog.com/node0.