Description

The new re-fetch merge logic builds a PK lookup key via row[c.propertyPath] and
entityId[c.propertyPath]. For embedded columns TypeORM represents values as nested objects (not
flat keys with dotted paths), so this lookup can produce undefined keys, causing fetched rows to
not match the correct entity (skipping merges or merging into the wrong entity).

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R264-293]

+                // Build a lookup from serialized PK → fetched row so that
+                // positional mis-ordering of getMany() results cannot cause
+                // values to be merged into the wrong entity.
+                const pkSerializer = (row: ObjectLiteral) =>
+                    metadata.primaryColumns
+                        .map((c) => row[c.propertyPath])
+                        .join("\0")
+                const resultByPk = new Map<string, any>(
+                    returningResult.map((row) => [pkSerializer(row), row]),
                )

-                this.queryRunner.manager.merge(
-                    metadata.target as any,
-                    entity,
-                    returningResult[entityIndex],
-                )
-            })
+                entitiesWithIds.forEach(({ index, entityId }) => {
+                    const key = metadata.primaryColumns
+                        .map((c) => entityId[c.propertyPath])
+                        .join("\0")
+                    const row = resultByPk.get(key)
+                    if (!row) return
+
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        generatedMaps[index],
+                        row,
+                    )
+
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        entities[index],
+                        row,
+                    )
+                })

Evidence

ReturningResultsEntityUpdator.insert serializes PKs using row[c.propertyPath] /
entityId[c.propertyPath]. But for embedded columns, TypeORM constructs nested maps (e.g., `{ data:
{ info: { id: ... }}}), not a flat object keyed by the dotted propertyPath`. Therefore
bracket-access using a dotted propertyPath won’t retrieve the PK value, breaking the lookup.

The codebase already uses JSON.stringify of a structured id object as a stable hash elsewhere, and
ColumnMetadata APIs exist to correctly access embedded values.

src/query-builder/ReturningResultsEntityUpdator.ts[264-293]
src/metadata/ColumnMetadata.ts[564-620]
src/metadata/EntityMetadata.ts[645-653]
src/query-builder/transformer/RawSqlResultsToEntityTransformer.ts[704-714]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ReturningResultsEntityUpdator.insert()` builds a lookup key for fetched rows using `row[c.propertyPath]` / `entityId[c.propertyPath]`. This breaks when primary columns are embedded (nested object structure), causing failed matches and potentially incorrect merge behavior.

### Issue Context
TypeORM represents embedded column value maps as nested objects (not flat objects keyed by dotted paths). The PK lookup should therefore be derived from an id map (e.g. `metadata.getEntityIdMap(...)`) or use `ColumnMetadata.getEntityValue(...)`, not bracket access by `propertyPath`.

### Fix Focus Areas
- src/query-builder/ReturningResultsEntityUpdator.ts[264-293]
- src/metadata/EntityMetadata.ts[645-653]
- src/metadata/ColumnMetadata.ts[564-620]
- src/query-builder/transformer/RawSqlResultsToEntityTransformer.ts[704-714]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

For drivers without RETURNING, the refetch query uses getMany() without an ORDER BY and then
merges returningResult[resultIndex] into entities[index] by positional index. SQL result
ordering is undefined without ORDER BY, so merged default/update-date/version values can be
applied to the wrong entity/generatedMap (silent data corruption), and this becomes reachable now
that entities can be skipped due to missing ids.

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R245-276]

+                const returningResult: any[] = await this.queryRunner.manager
+                    .createQueryBuilder()
+                    .select(
+                        metadata.primaryColumns.map(
+                            (column) =>
+                                metadata.targetName + "." + column.propertyPath,
+                        ),
+                    )
+                    .addSelect(
+                        insertionColumns.map(
+                            (column) =>
+                                metadata.targetName + "." + column.propertyPath,
+                        ),
+                    )
+                    .from(metadata.target, metadata.targetName)
+                    .where(entitiesWithIds.map((e) => e.entityId))
+                    .setOption("create-pojo") // use POJO because created object can contain default values, e.g. property = null and those properties might be overridden by merge process
+                    .getMany()

-            entities.forEach((entity, entityIndex) => {
-                this.queryRunner.manager.merge(
-                    metadata.target as any,
-                    generatedMaps[entityIndex],
-                    returningResult[entityIndex],
-                )
+                entitiesWithIds.forEach(({ index }, resultIndex) => {
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        generatedMaps[index],
+                        returningResult[resultIndex],
+                    )

-                this.queryRunner.manager.merge(
-                    metadata.target as any,
-                    entity,
-                    returningResult[entityIndex],
-                )
-            })
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        entities[index],
+                        returningResult[resultIndex],
+                    )
+                })

Evidence

The refetch SELECT has no ordering, and the merge logic assumes returningResult aligns 1:1 with
entitiesWithIds order. Meanwhile, where(ObjectLiteral[]) is compiled to OR-clauses, which
constrain matched rows but do not impose any ordering on the returned rows—so positional merging is
not safe.

src/query-builder/ReturningResultsEntityUpdator.ts[245-276]
src/query-builder/QueryBuilder.ts[1688-1715]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refetch/merge logic for non-RETURNING drivers merges reloaded rows into entities by array index, but the SELECT has no `ORDER BY`, so row order is not guaranteed. This can silently merge returned values (defaults/updateDate/version) into the wrong entity.
### Issue Context
- `.where(ObjectLiteral[])` becomes OR clauses that match the right rows but do not preserve any ordering.
- `getMany()` without ordering can return rows in arbitrary order.
### Fix Focus Areas
- src/query-builder/ReturningResultsEntityUpdator.ts[245-276]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

This PR changes upsert behavior to skip re-fetching entities without IDs instead of throwing,
which is user-facing for drivers without RETURNING support. The upsert documentation does not
describe this no-op/insertId=0 behavior, so users may be surprised by the changed outcome.

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R223-238]

+            // Collect only entities whose id is known. For upserts on drivers without
+            // RETURNING support (e.g. MySQL), a no-op upsert (identical values already
+            // in the DB) results in insertId=0, so the entity id is not set. In that
+            // case we skip the re-fetch for that entity rather than throwing.
+            const entitiesWithIds: {
+                entityId: ObjectLiteral
+                index: number
+            }[] = []
+            entities.forEach((entity, index) => {
+                const entityId = metadata.getEntityIdMap(entity)
+                if (entityId) {
+                    entitiesWithIds.push({ entityId, index })
+                }
           })

-            // to select just inserted entities we need a criteria to select by.
-            // for newly inserted entities in drivers which do not support returning statement
-            // row identifier can only be an increment column
-            // (since its the only thing that can be generated by those databases)
-            // or (and) other primary key which is defined by a user and inserted value has it
+            if (entitiesWithIds.length > 0) {

Evidence

The checklist requires documentation updates for user-facing behavior changes. The updated code
explicitly changes no-op upsert handling (skipping instead of throwing), while the existing upsert
docs only describe general upsert usage and returning support without mentioning the no-op upsert /
missing-id behavior.

Rule 2: Docs updated for user-facing changes
src/query-builder/ReturningResultsEntityUpdator.ts[223-226]
docs/docs/working-with-entity-manager/6-repository-api.md[175-210]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
This PR changes `upsert` behavior for drivers without RETURNING support by skipping the re-fetch when an entity ID is unavailable (e.g., MySQL no-op upsert returning `insertId=0`). The documentation does not mention this behavior change.
## Issue Context
The implementation comment in `ReturningResultsEntityUpdator` documents the scenario, but the public docs for `repository.upsert` / `manager.upsert` do not explain what to expect in no-op upserts on non-RETURNING drivers.
## Fix Focus Areas
- docs/docs/working-with-entity-manager/6-repository-api.md[175-257]
- docs/docs/working-with-entity-manager/5-entity-manager-api.md[217-237]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New JSDoc @param tags were added without any descriptions, which adds low-value comment noise.
This conflicts with the requirement to avoid AI-like or unnecessary comment additions.

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R26-30]

   /**
    * Updates entities with a special columns after updation query execution.
+     * @param updateResult
+     * @param entities
    */

Evidence

The checklist asks to avoid AI-generated noise such as extra comments; the added @param tags
provide no additional information because they lack descriptions.

Rule 4: Remove AI-generated noise
src/query-builder/ReturningResultsEntityUpdator.ts[26-30]
src/query-builder/ReturningResultsEntityUpdator.ts[136-140]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Two JSDoc blocks add `@param` tags without descriptions, creating unnecessary comment noise.
## Issue Context
The compliance checklist requires avoiding AI-like or low-value comment additions.
## Fix Focus Areas
- src/query-builder/ReturningResultsEntityUpdator.ts[26-30]
- src/query-builder/ReturningResultsEntityUpdator.ts[136-140]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The PR skips refetch (and no longer throws) when an entity id can’t be determined (e.g., MySQL
insertId=0 on a no-op upsert), but insertResult.identifiers is still populated for all entities
using metadata.getEntityIdMap(entity). For MySQL, createGeneratedMap won’t set an increment PK
when insertId is 0 (falsy), and getEntityIdMap (skipNulls) will return undefined, so
InsertResult.identifiers can contain undefined entries—violating its documented
ObjectLiteral[] contract and surprising callers.

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R223-236]

+            // Collect only entities whose id is known. For upserts on drivers without
+            // RETURNING support (e.g. MySQL), a no-op upsert (identical values already
+            // in the DB) results in insertId=0, so the entity id is not set. In that
+            // case we skip the re-fetch for that entity rather than throwing.
+            const entitiesWithIds: {
+                entityId: ObjectLiteral
+                index: number
+            }[] = []
+            entities.forEach((entity, index) => {
+                const entityId = metadata.getEntityIdMap(entity)
+                if (entityId) {
+                    entitiesWithIds.push({ entityId, index })
+                }
           })

Evidence

MySQL driver only populates increment PK when insertResult.insertId is truthy; with insertId=0, no
PK value is generated. getEntityIdMap skips null/undefined values and returns undefined when PK
is missing. With this PR, such entities are allowed to proceed (no throw), and the method still
pushes the (possibly undefined) id map into InsertResult.identifiers, despite
InsertResult.identifiers being documented as ObjectLiteral[].

src/query-builder/ReturningResultsEntityUpdator.ts[223-236]
src/driver/mysql/MysqlDriver.ts[976-1023]
src/metadata/EntityMetadata.ts[645-653]
src/query-builder/ReturningResultsEntityUpdator.ts[280-284]
src/query-builder/result/InsertResult.ts[14-24]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
After this PR, entities without determinable primary keys (e.g. MySQL no-op upsert with insertId=0 and no PK provided) are allowed to proceed, but `InsertResult.identifiers` is still filled using `getEntityIdMap(entity)` which can be `undefined`. This violates the documented `ObjectLiteral[]` contract and can break callers.
### Issue Context
- MySQL `createGeneratedMap` only sets increment PK when `insertResult.insertId` is truthy.
- `EntityMetadata.getEntityIdMap` uses `skipNulls: true` and returns `undefined` when PK values are missing.
### Fix Focus Areas
- src/query-builder/ReturningResultsEntityUpdator.ts[223-236]
- src/query-builder/ReturningResultsEntityUpdator.ts[280-284]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

On MySQL/Aurora when an upsert returns insertId=0, the driver-generated map can include the
primary key with value undefined, which then gets merged into the entity and returned in
InsertResult.generatedMaps. With this PR skipping the re-fetch/throw path, callers can now observe
mutated entities and generatedMaps containing id: undefined.

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R219-299]

+            // Collect only entities whose id is known. For upserts on drivers without
+            // RETURNING support (e.g. MySQL), a no-op upsert (identical values already
+            // in the DB) results in insertId=0, so the entity id is not set. In that
+            // case we skip the re-fetch for that entity rather than throwing.
+            const entitiesWithIds: {
+                entityId: ObjectLiteral
+                index: number
+            }[] = []
+            entities.forEach((entity, index) => {
+                const entityId = metadata.getEntityIdMap(entity)
+                if (entityId) {
+                    entitiesWithIds.push({ entityId, index })
+                }
            })

-            // to select just inserted entities we need a criteria to select by.
-            // for newly inserted entities in drivers which do not support returning statement
-            // row identifier can only be an increment column
-            // (since its the only thing that can be generated by those databases)
-            // or (and) other primary key which is defined by a user and inserted value has it
+            if (entitiesWithIds.length > 0) {
+                // to select just inserted entities we need a criteria to select by.
+                // for newly inserted entities in drivers which do not support returning statement
+                // row identifier can only be an increment column
+                // (since its the only thing that can be generated by those databases)
+                // or (and) other primary key which is defined by a user and inserted value has it

-            const returningResult: any = await this.queryRunner.manager
-                .createQueryBuilder()
-                .select(
-                    metadata.primaryColumns.map(
-                        (column) =>
-                            metadata.targetName + "." + column.propertyPath,
-                    ),
-                )
-                .addSelect(
-                    insertionColumns.map(
-                        (column) =>
-                            metadata.targetName + "." + column.propertyPath,
-                    ),
-                )
-                .from(metadata.target, metadata.targetName)
-                .where(entityIds)
-                .setOption("create-pojo") // use POJO because created object can contain default values, e.g. property = null and those properties might be overridden by merge process
-                .getMany()
+                const returningResult: any[] = await this.queryRunner.manager
+                    .createQueryBuilder()
+                    .select(
+                        metadata.primaryColumns.map(
+                            (column) =>
+                                metadata.targetName + "." + column.propertyPath,
+                        ),
+                    )
+                    .addSelect(
+                        insertionColumns.map(
+                            (column) =>
+                                metadata.targetName + "." + column.propertyPath,
+                        ),
+                    )
+                    .from(metadata.target, metadata.targetName)
+                    .where(entitiesWithIds.map((e) => e.entityId))
+                    .setOption("create-pojo") // use POJO because created object can contain default values, e.g. property = null and those properties might be overridden by merge process
+                    .getMany()

-            entities.forEach((entity, entityIndex) => {
-                this.queryRunner.manager.merge(
-                    metadata.target as any,
-                    generatedMaps[entityIndex],
-                    returningResult[entityIndex],
+                // Build a lookup from serialized PK → fetched row so that
+                // positional mis-ordering of getMany() results cannot cause
+                // values to be merged into the wrong entity.
+                // Use getEntityValue() so embedded PKs (nested objects) are
+                // resolved correctly instead of flat bracket-access by propertyPath.
+                const pkSerializer = (row: ObjectLiteral) =>
+                    metadata.primaryColumns
+                        .map((c) => c.getEntityValue(row))
+                        .join("\0")
+                const resultByPk = new Map<string, any>(
+                    returningResult.map((row) => [pkSerializer(row), row]),
                )

-                this.queryRunner.manager.merge(
-                    metadata.target as any,
-                    entity,
-                    returningResult[entityIndex],
-                )
-            })
+                entitiesWithIds.forEach(({ index, entityId }) => {
+                    const key = metadata.primaryColumns
+                        .map((c) => c.getEntityValue(entityId))
+                        .join("\0")
+                    const row = resultByPk.get(key)
+                    if (!row) return
+
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        generatedMaps[index],
+                        row,
+                    )
+
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        entities[index],
+                        row,
+                    )
+                })
+            }
        }

        entities.forEach((entity, entityIndex) => {
-            const entityId = metadata.getEntityIdMap(entity)!
+            const entityId = metadata.getEntityIdMap(entity) ?? {}
            insertResult.identifiers.push(entityId)
            insertResult.generatedMaps.push(generatedMaps[entityIndex])
        })

Evidence

ReturningResultsEntityUpdator.insert always merges the driver’s generated map into the passed
entity, but for MySQL/Aurora the driver can build a value map for an increment PK even when
insertId is falsy (e.g. 0), producing { id: undefined }. Because
ColumnMetadata.createValueMap includes keys even when the value is undefined, and
OrmUtils.merge assigns primitives as-is, this can overwrite an existing id and leaks into
InsertResult.generatedMaps; the PR then skips the re-fetch for entities without ids and pushes
{} identifiers, so the undefined-PK generatedMap is no longer “caught” by a throw/re-fetch step.

src/query-builder/ReturningResultsEntityUpdator.ts[154-209]
src/query-builder/ReturningResultsEntityUpdator.ts[219-233]
src/query-builder/ReturningResultsEntityUpdator.ts[295-299]
src/driver/mysql/MysqlDriver.ts[976-1023]
src/driver/aurora-mysql/AuroraMysqlDriver.ts[883-912]
src/metadata/ColumnMetadata.ts[564-619]
src/util/OrmUtils.ts[581-634]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
For MySQL/Aurora, `createGeneratedMap()` can produce `{ id: undefined }` for increment PKs when `insertId` is falsy (notably `0` on upsert update/no-op). `ReturningResultsEntityUpdator.insert()` merges this into the input entity and also returns it via `InsertResult.generatedMaps`, which is confusing and can wipe an explicitly-provided id.

### Issue Context
This PR intentionally skips re-fetching and throwing when entity id cannot be determined. That makes it more important that we do not merge/return “generated” PK fields with `undefined` values.

### Fix Focus Areas
- src/driver/mysql/MysqlDriver.ts[976-1023]
- src/driver/aurora-mysql/AuroraMysqlDriver.ts[883-912]
- src/query-builder/ReturningResultsEntityUpdator.ts[154-209]

### Suggested direction
Prefer fixing in the drivers:
- Only `mergeDeep` a generated column’s value map if the computed `value` is not `undefined` (and potentially not `null`). This will cause `Object.keys(generatedMap).length` to be `0` and `createGeneratedMap` to return `undefined`, avoiding `{id: undefined}`.

Alternative / additional guard:
- In `ReturningResultsEntityUpdator.insert`, deep-prune `undefined` leaves from `generatedMap` before merging into `entity` and before storing it in `generatedMaps`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new re-fetch merge logic builds a PK lookup key via row[c.propertyPath] and
entityId[c.propertyPath]. For embedded columns TypeORM represents values as nested objects (not
flat keys with dotted paths), so this lookup can produce undefined keys, causing fetched rows to
not match the correct entity (skipping merges or merging into the wrong entity).

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R264-293]

+                // Build a lookup from serialized PK → fetched row so that
+                // positional mis-ordering of getMany() results cannot cause
+                // values to be merged into the wrong entity.
+                const pkSerializer = (row: ObjectLiteral) =>
+                    metadata.primaryColumns
+                        .map((c) => row[c.propertyPath])
+                        .join("\0")
+                const resultByPk = new Map<string, any>(
+                    returningResult.map((row) => [pkSerializer(row), row]),
               )

-                this.queryRunner.manager.merge(
-                    metadata.target as any,
-                    entity,
-                    returningResult[entityIndex],
-                )
-            })
+                entitiesWithIds.forEach(({ index, entityId }) => {
+                    const key = metadata.primaryColumns
+                        .map((c) => entityId[c.propertyPath])
+                        .join("\0")
+                    const row = resultByPk.get(key)
+                    if (!row) return
+
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        generatedMaps[index],
+                        row,
+                    )
+
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        entities[index],
+                        row,
+                    )
+                })

Evidence

ReturningResultsEntityUpdator.insert serializes PKs using row[c.propertyPath] /
entityId[c.propertyPath]. But for embedded columns, TypeORM constructs nested maps (e.g., `{ data:
{ info: { id: ... }}}), not a flat object keyed by the dotted propertyPath`. Therefore
bracket-access using a dotted propertyPath won’t retrieve the PK value, breaking the lookup. The
codebase already uses JSON.stringify of a structured id object as a stable hash elsewhere, and
ColumnMetadata APIs exist to correctly access embedded values.

src/query-builder/ReturningResultsEntityUpdator.ts[264-293]
src/metadata/ColumnMetadata.ts[564-620]
src/metadata/EntityMetadata.ts[645-653]
src/query-builder/transformer/RawSqlResultsToEntityTransformer.ts[704-714]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ReturningResultsEntityUpdator.insert()` builds a lookup key for fetched rows using `row[c.propertyPath]` / `entityId[c.propertyPath]`. This breaks when primary columns are embedded (nested object structure), causing failed matches and potentially incorrect merge behavior.
### Issue Context
TypeORM represents embedded column value maps as nested objects (not flat objects keyed by dotted paths). The PK lookup should therefore be derived from an id map (e.g. `metadata.getEntityIdMap(...)`) or use `ColumnMetadata.getEntityValue(...)`, not bracket access by `propertyPath`.
### Fix Focus Areas
- src/query-builder/ReturningResultsEntityUpdator.ts[264-293]
- src/metadata/EntityMetadata.ts[645-653]
- src/metadata/ColumnMetadata.ts[564-620]
- src/query-builder/transformer/RawSqlResultsToEntityTransformer.ts[704-714]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

For drivers without RETURNING, the refetch query uses getMany() without an ORDER BY and then
merges returningResult[resultIndex] into entities[index] by positional index. SQL result
ordering is undefined without ORDER BY, so merged default/update-date/version values can be
applied to the wrong entity/generatedMap (silent data corruption), and this becomes reachable now
that entities can be skipped due to missing ids.

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R245-276]

+                const returningResult: any[] = await this.queryRunner.manager
+                    .createQueryBuilder()
+                    .select(
+                        metadata.primaryColumns.map(
+                            (column) =>
+                                metadata.targetName + "." + column.propertyPath,
+                        ),
+                    )
+                    .addSelect(
+                        insertionColumns.map(
+                            (column) =>
+                                metadata.targetName + "." + column.propertyPath,
+                        ),
+                    )
+                    .from(metadata.target, metadata.targetName)
+                    .where(entitiesWithIds.map((e) => e.entityId))
+                    .setOption("create-pojo") // use POJO because created object can contain default values, e.g. property = null and those properties might be overridden by merge process
+                    .getMany()
-            entities.forEach((entity, entityIndex) => {
-                this.queryRunner.manager.merge(
-                    metadata.target as any,
-                    generatedMaps[entityIndex],
-                    returningResult[entityIndex],
-                )
+                entitiesWithIds.forEach(({ index }, resultIndex) => {
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        generatedMaps[index],
+                        returningResult[resultIndex],
+                    )
-                this.queryRunner.manager.merge(
-                    metadata.target as any,
-                    entity,
-                    returningResult[entityIndex],
-                )
-            })
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        entities[index],
+                        returningResult[resultIndex],
+                    )
+                })

Evidence

The refetch SELECT has no ordering, and the merge logic assumes returningResult aligns 1:1 with
entitiesWithIds order. Meanwhile, where(ObjectLiteral[]) is compiled to OR-clauses, which
constrain matched rows but do not impose any ordering on the returned rows—so positional merging is
not safe.

src/query-builder/ReturningResultsEntityUpdator.ts[245-276]
src/query-builder/QueryBuilder.ts[1688-1715]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refetch/merge logic for non-RETURNING drivers merges reloaded rows into entities by array index, but the SELECT has no `ORDER BY`, so row order is not guaranteed. This can silently merge returned values (defaults/updateDate/version) into the wrong entity.
### Issue Context
- `.where(ObjectLiteral[])` becomes OR clauses that match the right rows but do not preserve any ordering.
- `getMany()` without ordering can return rows in arbitrary order.
### Fix Focus Areas
- src/query-builder/ReturningResultsEntityUpdator.ts[245-276]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new PK→row matching uses a string serialization (join("\0")) that relies on JS string coercion
and a delimiter that could appear in string PK values. In rare edge cases (e.g., PK values
containing \0 or non-string PKs with ambiguous toString()), it could map fetched rows to the
wrong entity.

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R260-291]

+                // Build a lookup from serialized PK → fetched row so that
+                // positional mis-ordering of getMany() results cannot cause
+                // values to be merged into the wrong entity.
+                // Use getEntityValue() so embedded PKs (nested objects) are
+                // resolved correctly instead of flat bracket-access by propertyPath.
+                const pkSerializer = (row: ObjectLiteral) =>
+                    metadata.primaryColumns
+                        .map((c) => c.getEntityValue(row))
+                        .join("\0")
+                const resultByPk = new Map<string, any>(
+                    returningResult.map((row) => [pkSerializer(row), row]),
                )

-                this.queryRunner.manager.merge(
-                    metadata.target as any,
-                    entity,
-                    returningResult[entityIndex],
-                )
-            })
+                entitiesWithIds.forEach(({ index, entityId }) => {
+                    const key = metadata.primaryColumns
+                        .map((c) => c.getEntityValue(entityId))
+                        .join("\0")
+                    const row = resultByPk.get(key)
+                    if (!row) return
+
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        generatedMaps[index],
+                        row,
+                    )
+
+                    this.queryRunner.manager.merge(
+                        metadata.target as any,
+                        entities[index],
+                        row,
+                    )
+                })

Evidence

The lookup key is built by concatenating primary key values into a single string via join("\0")
both for result rows and for entityId maps, without escaping or type-tagging. This is generally
fine for common PKs (numbers/UUIDs), but the approach is not collision-proof for arbitrary PK
types/values.

src/query-builder/ReturningResultsEntityUpdator.ts[260-271]
src/query-builder/ReturningResultsEntityUpdator.ts[273-277]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
PK matching relies on `values.join("\0")`, which can theoretically collide if values contain the delimiter or stringify ambiguously.

### Issue Context
This logic is used to avoid positional mismatches from `getMany()` ordering; improving the serializer would preserve that benefit while reducing edge-case collision risk.

### Fix Focus Areas
- src/query-builder/ReturningResultsEntityUpdator.ts[260-277]

### Suggested direction
- Build keys as an array of per-column components with explicit type tags and escaping, e.g.:
 - `const key = metadata.primaryColumns.map(c => {
       const v = c.getEntityValue(x)
       return `${typeof v}:${String(v).replaceAll("\\0", "\\0\\0")}`
    }).join("\\0")`
- Alternatively, serialize per-column values using `JSON.stringify` of the ordered array (with a replacer for Buffer/Date as needed).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

This PR changes upsert behavior to skip re-fetching entities without IDs instead of throwing,
which is user-facing for drivers without RETURNING support. The upsert documentation does not
describe this no-op/insertId=0 behavior, so users may be surprised by the changed outcome.

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R223-238]

+            // Collect only entities whose id is known. For upserts on drivers without
+            // RETURNING support (e.g. MySQL), a no-op upsert (identical values already
+            // in the DB) results in insertId=0, so the entity id is not set. In that
+            // case we skip the re-fetch for that entity rather than throwing.
+            const entitiesWithIds: {
+                entityId: ObjectLiteral
+                index: number
+            }[] = []
+            entities.forEach((entity, index) => {
+                const entityId = metadata.getEntityIdMap(entity)
+                if (entityId) {
+                    entitiesWithIds.push({ entityId, index })
+                }
          })
-            // to select just inserted entities we need a criteria to select by.
-            // for newly inserted entities in drivers which do not support returning statement
-            // row identifier can only be an increment column
-            // (since its the only thing that can be generated by those databases)
-            // or (and) other primary key which is defined by a user and inserted value has it
+            if (entitiesWithIds.length > 0) {

Evidence

The checklist requires documentation updates for user-facing behavior changes. The updated code
explicitly changes no-op upsert handling (skipping instead of throwing), while the existing upsert
docs only describe general upsert usage and returning support without mentioning the no-op upsert /
missing-id behavior.

Rule 2: Docs updated for user-facing changes
src/query-builder/ReturningResultsEntityUpdator.ts[223-226]
docs/docs/working-with-entity-manager/6-repository-api.md[175-210]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
This PR changes `upsert` behavior for drivers without RETURNING support by skipping the re-fetch when an entity ID is unavailable (e.g., MySQL no-op upsert returning `insertId=0`). The documentation does not mention this behavior change.
## Issue Context
The implementation comment in `ReturningResultsEntityUpdator` documents the scenario, but the public docs for `repository.upsert` / `manager.upsert` do not explain what to expect in no-op upserts on non-RETURNING drivers.
## Fix Focus Areas
- docs/docs/working-with-entity-manager/6-repository-api.md[175-257]
- docs/docs/working-with-entity-manager/5-entity-manager-api.md[217-237]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New JSDoc @param tags were added without any descriptions, which adds low-value comment noise.
This conflicts with the requirement to avoid AI-like or unnecessary comment additions.

Code

src/query-builder/ReturningResultsEntityUpdator.ts[R26-30]

  /**
   * Updates entities with a special columns after updation query execution.
+     * @param updateResult
+     * @param entities
   */

Evidence

The checklist asks to avoid AI-generated noise such as extra comments; the added @param tags
provide no additional information because they lack descriptions.

Rule 4: Remove AI-generated noise
src/query-builder/ReturningResultsEntityUpdator.ts[26-30]
src/query-builder/ReturningResultsEntityUpdator.ts[136-140]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Two JSDoc blocks add `@param` tags without descriptions, creating unnecessary comment noise.
## Issue Context
The compliance checklist requires avoiding AI-like or low-value comment additions.
## Fix Focus Areas
- src/query-builder/ReturningResultsEntityUpdator.ts[26-30]
- src/query-builder/ReturningResultsEntityUpdator.ts[136-140]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools