Pull Request Checklist

• Have you added new tests to prevent regressions?
• If a documentation update is necessary, have you opened a PR to the documentation repository?
• Did you update the typescript typings accordingly (if applicable)?
• Does the description below contain a link to an existing issue (Closes #[issue]) or a description of the issue you are solving?
• Does the name of your PR follow our conventions?

Description of Changes

Closes #18306
Closes #18307
Closes #18286

A condition whose operand set turns out to be empty, or to contain NULL, compiled to SQL
that did not mean what the condition meant. The mismatch was invisible on its own and only
surfaced once the condition was composed — which is why it kept being fixed one operator at a
time (#4859, #18248 / #18250, #18286, #18306) without the class ever closing.

1. An empty Op.in / Op.notIn compiles to a truth value

{ [Op.in]: [] } emitted IN (NULL), which is UNKNOWN rather than FALSE. UNKNOWN is
indistinguishable from FALSE at the top of a WHERE, so the bare case looked right — but
NOT (UNKNOWN) is still UNKNOWN, so negating it matched no rows where it should match
every row.

This is not a judgement call: SQL defines x IN (…) as x = ANY (…), and an existential
quantifier over an empty set is FALSE for every x, NULL included. You can observe it
directly, because SQL does have a syntax for an empty right-hand side:

SELECT NULL::int IN     (SELECT 1 WHERE false);  -- f    <- FALSE, not NULL
SELECT NULL::int NOT IN (SELECT 1 WHERE false);  -- t
SELECT NULL::int IN     (NULL);                  -- NULL <- what Sequelize emitted

Identical on MySQL. Every ORM I checked emits a constant here and none throws: ActiveRecord
1=0/1=1 (arel/visitors/to_sql.rb), Knex 1 = 0/1 = 1, TypeORM 0=1, SQLAlchemy
(col IN (NULL)) AND (1 != 1), Django raises EmptyResultSet internally and converts it to
a full result set under exclude().

2. A NULL inside a list is compared separately

x NOT IN (1, NULL) is UNKNOWN for every row, so it silently matched nothing on every
dialect, and x IN (1, NULL) never matched a NULL x. Sequelize already rewrites
{ x: null } to x IS NULL rather than emitting x = NULL; the same now happens inside a
list:

[Op.in]:    [1, null] -> x IN (1) OR x IS NULL
[Op.notIn]: [1, null] -> x NOT IN (1) AND x IS NOT NULL
[Op.in]:    [null]    -> x IS NULL

Django strips None for the same reason ("NULL is never equal to anything"); ActiveRecord
ORs in attribute.eq(nil), which is the behaviour chosen here.

The typings accept null for nullable attributes. That needed WhereAttributeHashValue's
conditional to become non-distributive — for number | null it otherwise instantiates the
operator table once for number and once for null, and neither arm accepts a list
containing both.

3. Truth values are tracked instead of overloading the empty string

joinWithLogicalOperator and wrapWithNot dropped '' unconditionally — including from an
OR, whose identity is FALSE rather than TRUE, and from a NOT, where dropping it is never
right. That single behaviour is the shared cause of #18248, #18306 and #18286.

Fragments now carry NO_CONDITION / ALWAYS_TRUE / ALWAYS_FALSE, and AND, OR and NOT do
boolean algebra over them.

An Op.or arm that carries no condition contributes nothing rather than satisfying the
whole disjunction, so { [Op.or]: [maybeFilter, cond] } still means cond when the first arm
is absent. That distinction — an OR with an empty arm versus an OR with no arms — is what
keeps the common optional-filter idiom working.

This supersedes #18286, which fixes the same cases by throwing. The literal is chosen here
because the empty set has a defined meaning in SQL (§1) and because Op.notIn: [] was already
settled that way in #18250. The Op.and asymmetry that PR calls out is preserved and pinned
by tests.

4. Statements that modify rows refuse a where that imposes no restriction

Model.destroy, Model.update and Model.increment / Model.decrement only checked that a
where was passed, not what it meant — so { id: { [Op.notIn]: [] } } compiled to
WHERE 1 = 1 and rewrote the whole table. This is what @SippieCup asked for in #18307.

They now check the caller's where on its own, immediately before a scope or a paranoid
clause is merged into it — the last point at which options.where is purely what the caller
asked for.

Model.destroy({ where: { id: { [Op.notIn]: [] } } })          // throws
Model.destroy({ where: { [Op.not]: { id: { [Op.in]: [] } } } }) // throws
Model.destroy({ where: { tenantId: 5, id: { [Op.notIn]: [] } } }) // runs — the tenant filter is real
Model.destroy({ where: sql`1 = 1` })                          // runs — the documented escape hatch
Model.destroy({ where: {} })                                  // runs — unchanged
Model.findAll({ where: { id: { [Op.notIn]: [] } } })          // reads are untouched

Judging the caller's conditions rather than the compiled statement is what keeps the third
line working while still catching the first on a paranoid or scoped model — where the
injected deletedAt IS NULL would otherwise absorb the always-true condition and hide it.
QueryInterface#bulkDelete, #bulkUpdate and the increment path additionally reject an
always-true where for callers that use them directly.

That this check has to sit in a window rather than being a property of the compiled
statement is a symptom of scope and paranoid conditions being merged into the caller's
where at all. Filed as #18323 for a later re-architecture.

5. Where fragments are bracketed where they are concatenated by hand

Four sites build SQL by appending ` AND ${fragment}` instead of going through
joinWithLogicalOperator, so a fragment containing OR rebound:

ON "User"."id" = "…"."userId" AND "p"."tag" IN ('x') OR "p"."tag" IS NULL

which pulled unrelated rows into a belongsToMany include, and made Oracle's limited DELETE
ignore its own rownum limit. The bug predates this PR — an Op.or in an include.where hit
it too — but a null-bearing Op.in now produces an OR, which widens it a long way.

Verification

• Unit suite on all nine dialects: 2241–2867 passing, 0 failing
• PostgreSQL integration suite against a live server: 2103 passing, 0 failing
• Behaviour confirmed against live PostgreSQL 17, MySQL 8.4 and SQL Server 2025
• tsc --noEmit and tsc -b test/tsconfig.json clean

List of Breaking Changes

• or([]), or({}), { [Op.not]: {} } and { [Op.not]: [] } produce 0 = 1 instead of no
  condition at all. { [Op.and]: [] } and and({}) still produce no condition.
• Model.update, Model.destroy and Model.increment / Model.decrement throw when the
  caller's where compiles to a condition that is true for every row, such as
  { [Op.notIn]: [] }. Pass sql`1 = 1` to affect every row deliberately.
• A null inside an Op.in / Op.notIn list now means "or is null" instead of being passed
  through to SQL as a list element.
• A bare { [Op.in]: [] } emits 0 = 1 instead of IN (NULL). Equivalent inside a top-level
  WHERE, but code asserting on the exact generated SQL will see a difference.

Credit

§1 is @lazerg's fix from #18307, and the analysis it rests on is theirs — the diagnosis in
#18306 identified IN (NULL) as UNKNOWN rather than FALSE, corrected the assumption #18248
had been written on, and spotted that the Op.in describe block was missing the composition
cases that would have caught it. The write-path discussion in §4 follows their reasoning in
the #18307 thread, including the point that a guard belongs at the layer that already checks
for a missing where.

Created by Opus 5 with Claude Code, supervised by @WikiRik.

Summary by CodeRabbit

• Bug Fixes
  • Prevented accidental unrestricted UPDATE, DELETE, and increment/decrement operations when conditions match every row.
  • Corrected empty IN/NOT IN behavior, including handling of NULL values.
  • Improved grouping of conditions in generated JOIN and Oracle queries.
• Developer Experience
  • Added clearer errors when destructive operations would affect every row.
  • Improved TypeScript support for nullable IN values and query-safety options.
  • Preserved explicitly supplied always-true SQL conditions when intentionally requested.