Pull Request Checklist

• Have you added new tests to prevent regressions? No. This removes an undocumented behavior, and it deletes the five tests that asserted it, exactly as the v7 commit did.
• Does npm run test or npm run test-DIALECT pass with this change (including linting)? The unit suite passes, 1387 tests. eslint src/model.js test/unit/model/find-one.test.js is clean. See below.
• Is a documentation update included? No. This removes an undocumented behavior.
• Did you update the typescript typings accordingly? Not applicable. No signature changes.
• Does the description below contain a link to an existing issue? feat: Always add LIMIT 1 to findOne queries #14549, findOne does not add 'LIMIT 1' when first column of composite primary key is passed to 'where' option #13479, findOne doesn't generate a corrected SQL with partial primary key #9859.
• Did you follow the commit message conventions explained in CONTRIBUTING.md? Yes, the original commit message is preserved.

Description Of Change

This is a cherry-pick of 9950b4b, "feat: Always add LIMIT 1 to findOne queries" (#14549),
onto the v6 branch. It carries both files from the original commit: src/model.js and
the test removal.

#17726 already cherry-picked the same source change. @WikiRik noted in March 2025 that the
tests removed in 9950b4b are also present on v6, and that PR touches src/model.js only,
so those tests still fail. This PR closes that gap. I am happy to close this one if you
prefer to keep #17726 and land the test removal there instead.

Why the current behavior is wrong

findOne keeps LIMIT 1 off the query when the where clause names primaryKeyAttribute.
On a composite primary key, primaryKeyAttribute is only the first column. One value of
that column matches many rows, so the query returns all of them.

The same block already guards the equivalent case for unique keys. It filters uniqueKeys
down to c.fields.length === 1, so a multi-column unique key keeps its LIMIT. A
multi-column primary key gets no such guard:

Two earlier reports of this closed without a fix. #9859 (2018) closed with "Sequelize at
this time does not support partial primary keys, we recommend id as primary key", which no
longer holds. #13479 (2021) described the composite primary key case with an SSCCE, and the
stale bot closed it.

Reproduction on 6.37.8

const RunItem = sequelize.define('RunItem', {
  runId: {type: DataTypes.STRING, primaryKey: true},
  itemId: {type: DataTypes.STRING, primaryKey: true},
  status: {type: DataTypes.STRING},
}, {tableName: 'run_items', timestamps: false})

// three rows share runId 'r1' and status 'enqueued'
await RunItem.findOne({where: {runId: 'r1', status: 'enqueued'}})           // 1
await RunItem.findOne({where: {status: 'enqueued'}})                        // 2
await RunItem.findOne({where: {runId: 'r1', status: 'enqueued'}, limit: 1}) // 3

primaryKeyAttribute  : runId
primaryKeyAttributes : ["runId","itemId"]

1. SELECT ... WHERE "runId" = 'r1' AND "status" = 'enqueued';            <- no LIMIT
2. SELECT ... WHERE "status" = 'enqueued' LIMIT 1;
3. SELECT ... WHERE "runId" = 'r1' AND "status" = 'enqueued' LIMIT 1;

Case 2 is the proof. Drop the primary key column from the where clause and the LIMIT
comes back.

What it cost us

We used findOne as an existence probe on a table with the three-column primary key
(run_id, subject_id, subject_type). The where clause named run_id and a status, so
every call read every row of the run and built a model instance for each one.

EXPLAIN (ANALYZE, BUFFERS) on a copy of the production table, 180,687 matching rows:

All three plans take the same index-only scan with Heap Fetches: 0. No plan flip. Only the
row count differs. The probe ran about 147,000 times per nightly job, which added about
1,750 s of database time and 10 minutes of wall-clock to a 613-minute run.

The row count is also why this is more than a wire-format nicety. Those rows became 180,687
model instances per call, and no database metric showed it. Per-call database time rose only
from 17 ms to 29 ms.

Verification

The full unit suite on this branch:

$ node ./build.js && DIALECT=postgres npx mocha -r ./test/registerEsbuild "test/unit/**/*.test.[tj]s"
  1387 passing (500ms)

The two remaining cases in test/unit/model/find-one.test.js still pass, because both assert
that limit is present:

  [POSTGRES] Model
    method findOne
      ✓ should add limit when using { $ gt on the primary key
      ✓ should add limit when using multi-column unique key
  2 passing (8ms)

Restore the deleted tests and keep the source change, and exactly the five expected cases
fail, which is the gap #17726 leaves open:

        1) with id primary key
        2) with custom primary key
        3) with blob primary key
        4) with custom unique key
        5) with blob unique key
  2 passing
  5 failing
     AssertionError: expected { where: { id: 42 }, limit: 1, …(1) } to not have property 'limit'

grep -rn "uniqueSingleColumns" src/ test/ returns nothing after this change, and no other
test on v6 asserts the removed behavior.

Notes

• An explicit limit still wins. The if (options.limit === undefined) guard is unchanged,
  so the temporary workaround for Deleting PK column does not prevent MSSQL from ordering by PK on LIMIT 1 queries. #14618 carries over exactly as written in 9950b4b.
• I did not touch the integration suite. I have no MSSQL or DB2 instance to hand, and Deleting PK column does not prevent MSSQL from ordering by PK on LIMIT 1 queries. #14618
  is the known MSSQL interaction, already handled by the guard above.