A guard on the filter map in the data proxy. Any filter key whose value is undefined causes a 400 with a message naming the key, instead of being dropped. Client-supplied org_id is always discarded and re-applied from the session. Explicit nulls are handled separately and correctly as IS NULL.
Also called: undefined filter · query ran too wide · wrong customer's total appeared
- 1Client filters are copied into a sanitised map before use.
- 2Any org_id key is dropped so the authoritative one can be re-applied.
- 3A value of undefined returns a 400 naming the offending key and telling the caller to resolve it before calling.
- 4An explicit null is translated to IS NULL, because equality against null is rejected by typed columns.
This guard is the direct product of L2B-HMN3V9, and the comment records the exact shape of the bug: a call site wrote `estimate_link_id: someRow.id ?? undefined`, the undefined value could not survive JSON, 'so the query silently ran WIDER than the caller wrote' and returned the newest contract in the account — 'so one customer's signed total appeared on another customer's invoice.' The comment is honest about the limits of the fix: 'We cannot see the key that vanished, but we can refuse the one shape that does arrive.' A widened query inside a single account is not a cross-account leak, but it is exactly the class of silent error that produces a wrong number on a real document.
- A dropped filter turned a targeted lookup into 'whatever is newest', producing a wrong number on a customer document.
- The failure was silent — the query succeeded, it just answered a different question.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →