Description

The new lazy-relation branch reads entity[this.propertyName] (including inside an `instanceof
Promise` check), which can invoke the lazy getter and start DB queries unexpectedly, and can also
return a Promise to callers that expect concrete relation values or undefined. This can cause
unexpected queries during initialization/validation and break persistence/transform flows when an
unresolved Promise is returned.

Code

src/metadata/RelationMetadata.ts[R482-491]

+                if (
+                    !Object.getOwnPropertyDescriptor(
+                        entity,
+                        this.propertyName,
+                    )?.get &&
+                    entity[this.propertyName] instanceof Promise
+                ) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

RelationLoader.enableLazyLoad defines a getter for lazy relations that calls
relationLoader.load(...) (DB query) when the property is accessed. EntityMetadata.create applies
this lazy getter to created instances. Then EntityMetadataValidator calls
relation.getEntityValue(entityInstance) during initialization just to detect initialized arrays;
with the new getEntityValue implementation, accessing entity[this.propertyName] can invoke the
getter, triggering unexpected queries and returning a Promise (ignored/not awaited), which can lead
to performance regressions and potential unhandled rejections.

src/metadata/RelationMetadata.ts[468-494]
src/query-builder/RelationLoader.ts[409-477]
src/metadata/EntityMetadata.ts[564-595]
src/metadata-builder/EntityMetadataValidator.ts[200-220]

Agent prompt

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

## Issue description
`RelationMetadata.getEntityValue` now accesses `entity[this.propertyName]` for lazy relations even when `getLazyRelationsPromiseValue` is `false`. If `this.propertyName` is a lazy-loading getter (as installed by `RelationLoader.enableLazyLoad`), that access can trigger a DB query and/or return a Promise into code paths that expect a concrete value or `undefined`.
### Issue Context
- Lazy relations are implemented using `Object.defineProperty(..., { get() { ... relationLoader.load(...) } })`.
- Multiple call sites (e.g. metadata validation and persistence subject building) call `getEntityValue(entity)` with the default flag and do not expect to cause IO or to receive a Promise.
### Fix Focus Areas
- src/metadata/RelationMetadata.ts[475-493]

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

Description

The new lazy-relation getter detection calls Object.getOwnPropertyDescriptor on
Object.getPrototypeOf(entity) without guarding against a null prototype, which can throw a TypeError
and break persistence/transform flows operating on plain objects.

Code

src/metadata/RelationMetadata.ts[R482-488]

+                const hasGetter =
+                    Object.getOwnPropertyDescriptor(entity, this.propertyName)
+                        ?.get ||
+                    Object.getOwnPropertyDescriptor(
+                        Object.getPrototypeOf(entity),
+                        this.propertyName,
+                    )?.get

Evidence

RelationMetadata.getEntityValue now unconditionally passes Object.getPrototypeOf(entity) into
Object.getOwnPropertyDescriptor; if prototype is null, that call throws. TypeORM code explicitly
considers Object.create(null) objects as “plain objects”, and relation.getEntityValue is invoked on
user-provided plain objects during transformation/merge operations, making this a plausible runtime
crash.

src/metadata/RelationMetadata.ts[475-493]
src/util/OrmUtils.ts[538-545]
src/query-builder/transformer/PlainObjectToNewEntityTransformer.ts[56-64]

Agent prompt

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

## Issue description
`RelationMetadata.getEntityValue` calls `Object.getOwnPropertyDescriptor(Object.getPrototypeOf(entity), ...)` without checking if the prototype is `null`. For `Object.create(null)`-style objects, `Object.getPrototypeOf(entity)` returns `null`, and `Object.getOwnPropertyDescriptor(null, ...)` throws a `TypeError`.
## Issue Context
TypeORM utilities explicitly treat `Object.create(null)` objects as valid “plain objects”, and `relation.getEntityValue(...)` is called on user-provided plain objects in transformers.
## Fix Focus Areas
- src/metadata/RelationMetadata.ts[482-488]

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

Description

The new lazy-relation branch reads entity[this.propertyName] (including inside an `instanceof
Promise` check), which can invoke the lazy getter and start DB queries unexpectedly, and can also
return a Promise to callers that expect concrete relation values or undefined. This can cause
unexpected queries during initialization/validation and break persistence/transform flows when an
unresolved Promise is returned.

Code

src/metadata/RelationMetadata.ts[R482-491]

+                if (
+                    !Object.getOwnPropertyDescriptor(
+                        entity,
+                        this.propertyName,
+                    )?.get &&
+                    entity[this.propertyName] instanceof Promise
+                ) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

RelationLoader.enableLazyLoad defines a getter for lazy relations that calls
relationLoader.load(...) (DB query) when the property is accessed. EntityMetadata.create applies
this lazy getter to created instances. Then EntityMetadataValidator calls
relation.getEntityValue(entityInstance) during initialization just to detect initialized arrays;
with the new getEntityValue implementation, accessing entity[this.propertyName] can invoke the
getter, triggering unexpected queries and returning a Promise (ignored/not awaited), which can lead
to performance regressions and potential unhandled rejections.

src/metadata/RelationMetadata.ts[468-494]
src/query-builder/RelationLoader.ts[409-477]
src/metadata/EntityMetadata.ts[564-595]
src/metadata-builder/EntityMetadataValidator.ts[200-220]

Agent prompt

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

## Issue description
`RelationMetadata.getEntityValue` now accesses `entity[this.propertyName]` for lazy relations even when `getLazyRelationsPromiseValue` is `false`. If `this.propertyName` is a lazy-loading getter (as installed by `RelationLoader.enableLazyLoad`), that access can trigger a DB query and/or return a Promise into code paths that expect a concrete value or `undefined`.
### Issue Context
- Lazy relations are implemented using `Object.defineProperty(..., { get() { ... relationLoader.load(...) } })`.
- Multiple call sites (e.g. metadata validation and persistence subject building) call `getEntityValue(entity)` with the default flag and do not expect to cause IO or to receive a Promise.
### Fix Focus Areas
- src/metadata/RelationMetadata.ts[475-493]

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

Description

The new lazy-relation getter detection calls Object.getOwnPropertyDescriptor on
Object.getPrototypeOf(entity) without guarding against a null prototype, which can throw a TypeError
and break persistence/transform flows operating on plain objects.

Code

src/metadata/RelationMetadata.ts[R482-488]

+                const hasGetter =
+                    Object.getOwnPropertyDescriptor(entity, this.propertyName)
+                        ?.get ||
+                    Object.getOwnPropertyDescriptor(
+                        Object.getPrototypeOf(entity),
+                        this.propertyName,
+                    )?.get

Evidence

RelationMetadata.getEntityValue now unconditionally passes Object.getPrototypeOf(entity) into
Object.getOwnPropertyDescriptor; if prototype is null, that call throws. TypeORM code explicitly
considers Object.create(null) objects as “plain objects”, and relation.getEntityValue is invoked on
user-provided plain objects during transformation/merge operations, making this a plausible runtime
crash.

src/metadata/RelationMetadata.ts[475-493]
src/util/OrmUtils.ts[538-545]
src/query-builder/transformer/PlainObjectToNewEntityTransformer.ts[56-64]

Agent prompt

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

## Issue description
`RelationMetadata.getEntityValue` calls `Object.getOwnPropertyDescriptor(Object.getPrototypeOf(entity), ...)` without checking if the prototype is `null`. For `Object.create(null)`-style objects, `Object.getPrototypeOf(entity)` returns `null`, and `Object.getOwnPropertyDescriptor(null, ...)` throws a `TypeError`.
## Issue Context
TypeORM utilities explicitly treat `Object.create(null)` objects as valid “plain objects”, and `relation.getEntityValue(...)` is called on user-provided plain objects in transformers.
## Fix Focus Areas
- src/metadata/RelationMetadata.ts[482-488]

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

Description

The new lazy-relation branch reads entity[this.propertyName] (including inside an `instanceof
Promise` check), which can invoke the lazy getter and start DB queries unexpectedly, and can also
return a Promise to callers that expect concrete relation values or undefined. This can cause
unexpected queries during initialization/validation and break persistence/transform flows when an
unresolved Promise is returned.

Code

src/metadata/RelationMetadata.ts[R482-491]

+                if (
+                    !Object.getOwnPropertyDescriptor(
+                        entity,
+                        this.propertyName,
+                    )?.get &&
+                    entity[this.propertyName] instanceof Promise
+                ) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

RelationLoader.enableLazyLoad defines a getter for lazy relations that calls
relationLoader.load(...) (DB query) when the property is accessed. EntityMetadata.create applies
this lazy getter to created instances. Then EntityMetadataValidator calls
relation.getEntityValue(entityInstance) during initialization just to detect initialized arrays;
with the new getEntityValue implementation, accessing entity[this.propertyName] can invoke the
getter, triggering unexpected queries and returning a Promise (ignored/not awaited), which can lead
to performance regressions and potential unhandled rejections.

src/metadata/RelationMetadata.ts[468-494]
src/query-builder/RelationLoader.ts[409-477]
src/metadata/EntityMetadata.ts[564-595]
src/metadata-builder/EntityMetadataValidator.ts[200-220]

Agent prompt

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

## Issue description
`RelationMetadata.getEntityValue` now accesses `entity[this.propertyName]` for lazy relations even when `getLazyRelationsPromiseValue` is `false`. If `this.propertyName` is a lazy-loading getter (as installed by `RelationLoader.enableLazyLoad`), that access can trigger a DB query and/or return a Promise into code paths that expect a concrete value or `undefined`.
### Issue Context
- Lazy relations are implemented using `Object.defineProperty(..., { get() { ... relationLoader.load(...) } })`.
- Multiple call sites (e.g. metadata validation and persistence subject building) call `getEntityValue(entity)` with the default flag and do not expect to cause IO or to receive a Promise.
### Fix Focus Areas
- src/metadata/RelationMetadata.ts[475-493]

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

Description

Several new JSDoc @param tags were added without any descriptive text, adding comment noise and
style inconsistency. This conflicts with the requirement to avoid AI-like/low-value commentary
additions.

Code

src/metadata/RelationMetadata.ts[R413-414]

+     * @param entity
+     * @param getLazyRelationsPromiseValue

Evidence

PR Compliance ID 4 requires avoiding AI-generated noise and inconsistent style; the PR adds multiple
bare @param lines that provide no additional information (only parameter names).

Rule 4: Remove AI-generated noise
src/metadata/RelationMetadata.ts[410-415]
src/metadata/RelationMetadata.ts[600-605]

Agent prompt

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

## Issue description
Several JSDoc blocks add `@param <name>` entries with no descriptive text. These add low-value commentary and can be considered AI-generated noise / style inconsistency.
## Issue Context
The compliance checklist requires avoiding AI-like slop and inconsistent style. If parameter documentation is desired, it should include meaningful descriptions; otherwise, these tags should be removed.
## Fix Focus Areas
- src/metadata/RelationMetadata.ts[369-372]
- src/metadata/RelationMetadata.ts[385-392]
- src/metadata/RelationMetadata.ts[410-415]
- src/metadata/RelationMetadata.ts[499-506]
- src/metadata/RelationMetadata.ts[549-552]
- src/metadata/RelationMetadata.ts[600-605]
- src/metadata/RelationMetadata.ts[609-614]
- src/metadata/RelationMetadata.ts[632-636]

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

Description

The new prototype-chain scan treats the relation as “lazy/unassigned” if it finds any getter up the
chain, even when the entity defines its own data property that shadows that getter. In such cases
(e.g., entities/deserialized objects that define the property via defineProperty), an explicitly
assigned relation value can still be skipped during persistence.

Code

src/metadata/RelationMetadata.ts[R482-500]

+                let hasGetter = false
+                let proto: object | null = entity
+                while (proto) {
+                    if (
+                        Object.getOwnPropertyDescriptor(
+                            proto,
+                            this.propertyName,
+                        )?.get
+                    ) {
+                        hasGetter = true
+                        break
+                    }
+                    proto = Object.getPrototypeOf(proto)
+                }
+
+                if (hasGetter || entity[this.propertyName] instanceof Promise) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

RelationMetadata now walks the prototype chain and returns undefined whenever any getter is found,
without stopping when a shadowing own property descriptor exists. TypeORM installs lazy accessors on
the entity prototype, so the prototype chain commonly contains a getter for lazy relations; if a
consumer shadows it with a data property, this logic will still find the prototype getter and
incorrectly ignore the shadowing value.

src/metadata/RelationMetadata.ts[475-503]
src/metadata-builder/EntityMetadataBuilder.ts[397-409]

Agent prompt

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

## Issue description
`RelationMetadata.getEntityValue` scans the entire prototype chain for a getter and returns `undefined` if any getter exists, even if the relation name is shadowed by an own *data* property on the entity.
### Issue Context
This can cause explicitly assigned relation values to be ignored on entity-like objects that shadow the prototype accessor (e.g., via `Object.defineProperty` or certain deserialization patterns).
### Fix Focus Areas
- src/metadata/RelationMetadata.ts[482-500]

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

Description

The new assigned-value handling was only added for non-embedded relations; the embedded relation
branch still returns undefined for lazy relations unless ____ is populated. Since embeddeds can
contain relations, the same class of bug remains for embedded lazy relations.

Code

src/metadata/RelationMetadata.ts[R482-500]

+                let hasGetter = false
+                let proto: object | null = entity
+                while (proto) {
+                    if (
+                        Object.getOwnPropertyDescriptor(
+                            proto,
+                            this.propertyName,
+                        )?.get
+                    ) {
+                        hasGetter = true
+                        break
+                    }
+                    proto = Object.getPrototypeOf(proto)
+                }
+
+                if (hasGetter || entity[this.propertyName] instanceof Promise) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

RelationMetadata has a separate embeddedMetadata branch where lazy relations still always return
undefined unless the backing ____ exists or getLazyRelationsPromiseValue is true.
EmbeddedMetadata explicitly builds relationsFromTree, so relations-in-embedded is a
supported/considered feature and this branch is reachable.

src/metadata/RelationMetadata.ts[448-465]
src/metadata/EmbeddedMetadata.ts[308-314]

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 embedded-metadata branch of `RelationMetadata.getEntityValue` did not receive the new assigned-value handling for lazy relations, leaving embedded lazy relations unable to surface assigned values unless `__<prop>__` is set.
### Issue Context
Embeddeds can contain relations (`relationsFromTree`), so this branch is reachable for relation metadata.
### Fix Focus Areas
- src/metadata/RelationMetadata.ts[454-465]

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

Description

The added lazy test assigns Promise.resolve([...]), but save() yields await Promise.resolve()
before building subjects, allowing the lazy setter microtask to populate __posts__ so
getEntityValue returns early. This likely doesn’t exercise the newly added “no getter +
non-Promise value” code path, reducing confidence that the fix is validated.

Code

test/functional/persistence/one-to-many-lazy/persistence-one-to-many-lazy.test.ts[R77-85]

+                const fetchedUser = await entityManager.findOneOrFail(
+                    LazyUser,
+                    {
+                        where: { id: user.id },
+                    },
+                )
+                fetchedUser.posts = Promise.resolve([savedPost])
+                await entityManager.save(fetchedUser)
+

Evidence

RelationLoader.enableLazyLoad stores assigned Promises in __promise___ and transfers resolved
results into ____ in a .then(...) microtask. EntityPersistExecutor.execute begins by `await
Promise.resolve()` to flush microtasks before it proceeds to relation subject building, so by the
time persistence reads the relation, ____ is likely already set and the new getter/prototype
detection branch is bypassed.

test/functional/persistence/one-to-many-lazy/persistence-one-to-many-lazy.test.ts[77-85]
src/persistence/EntityPersistExecutor.ts[41-48]
src/query-builder/RelationLoader.ts[425-437]
src/query-builder/RelationLoader.ts[419-423]
src/metadata/RelationMetadata.ts[475-481]

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 new functional test likely passes without executing the newly added `hasGetter`/non-Promise-return path in `RelationMetadata.getEntityValue`, so it may not validate the intended fix.
### Issue Context
`EntityPersistExecutor` performs `await Promise.resolve()` before building relation subjects, which flushes microtasks that populate `__<prop>__` for `Promise.resolve(...)` assignments via the lazy setter.
### Fix Focus Areas
- test/functional/persistence/one-to-many-lazy/persistence-one-to-many-lazy.test.ts[59-96]
- src/persistence/EntityPersistExecutor.ts[46-48]
- src/query-builder/RelationLoader.ts[419-474]
- src/metadata/RelationMetadata.ts[475-500]

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

Description

Several new JSDoc @param tags were added without any descriptive text, adding comment noise and
style inconsistency. This conflicts with the requirement to avoid AI-like/low-value commentary
additions.

Code

src/metadata/RelationMetadata.ts[R413-414]

+     * @param entity
+     * @param getLazyRelationsPromiseValue

Evidence

PR Compliance ID 4 requires avoiding AI-generated noise and inconsistent style; the PR adds multiple
bare @param lines that provide no additional information (only parameter names).

Rule 4: Remove AI-generated noise
src/metadata/RelationMetadata.ts[410-415]
src/metadata/RelationMetadata.ts[600-605]

Agent prompt

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

## Issue description
Several JSDoc blocks add `@param <name>` entries with no descriptive text. These add low-value commentary and can be considered AI-generated noise / style inconsistency.
## Issue Context
The compliance checklist requires avoiding AI-like slop and inconsistent style. If parameter documentation is desired, it should include meaningful descriptions; otherwise, these tags should be removed.
## Fix Focus Areas
- src/metadata/RelationMetadata.ts[369-372]
- src/metadata/RelationMetadata.ts[385-392]
- src/metadata/RelationMetadata.ts[410-415]
- src/metadata/RelationMetadata.ts[499-506]
- src/metadata/RelationMetadata.ts[549-552]
- src/metadata/RelationMetadata.ts[600-605]
- src/metadata/RelationMetadata.ts[609-614]
- src/metadata/RelationMetadata.ts[632-636]

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

Description

The PR changes runtime behavior for lazy one-to-many relation value retrieval, which can affect
application behavior. No documentation changes were included to reflect this user-facing behavior
fix.

Code

src/metadata/RelationMetadata.ts[R482-493]

+                const hasGetter =
+                    Object.getOwnPropertyDescriptor(entity, this.propertyName)
+                        ?.get ||
+                    Object.getOwnPropertyDescriptor(
+                        Object.getPrototypeOf(entity),
+                        this.propertyName,
+                    )?.get
+
+                if (hasGetter || entity[this.propertyName] instanceof Promise) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

Compliance requires documentation updates for user-facing changes; the PR modifies lazy relation
handling logic but does not include any accompanying doc update in the provided changes, and the PR
checklist item for docs is left unchecked.

Rule 2: Docs updated for user-facing changes
src/metadata/RelationMetadata.ts[482-493]

Description

Getter detection only checks the entity and its immediate prototype, so a getter higher in the
prototype chain can be missed and inadvertently executed when evaluating entity[propertyName]. This
can cause unexpected side effects (including lazy-load queries) in edge cases with non-trivial
prototype chains (e.g., inheritance/mixins).

Code

src/metadata/RelationMetadata.ts[R482-493]

+                const hasGetter =
+                    Object.getOwnPropertyDescriptor(entity, this.propertyName)
+                        ?.get ||
+                    Object.getOwnPropertyDescriptor(
+                        Object.getPrototypeOf(entity),
+                        this.propertyName,
+                    )?.get
+
+                if (hasGetter || entity[this.propertyName] instanceof Promise) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

The implementation only inspects one prototype level for an accessor, then may read
entity[this.propertyName]. TypeORM supports inheritance trees, and lazy-load accessors are
installed via Object.defineProperty (including on prototypes), which makes deeper prototype chains
a realistic shape; walking the chain would make the getter-avoidance logic robust.

src/metadata/RelationMetadata.ts[482-493]
src/metadata-builder/EntityMetadataBuilder.ts[446-455]
src/query-builder/RelationLoader.ts[440-477]

Agent prompt

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

## Issue description
`RelationMetadata.getEntityValue()` only checks for an accessor getter on the object itself and its immediate prototype. If a getter exists higher in the prototype chain, the method can still end up evaluating `entity[propertyName]`, invoking the getter and potentially triggering unexpected side effects.
### Issue Context
TypeORM supports inheritance trees and installs lazy relation accessors via `Object.defineProperty` (including on prototypes). A safer approach is to walk the prototype chain when checking for accessors.
### Fix Focus Areas
- src/metadata/RelationMetadata.ts[482-493]

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

Description

Several new JSDoc @param tags were added without any descriptive text, adding comment noise and
style inconsistency. This conflicts with the requirement to avoid AI-like/low-value commentary
additions.

Code

src/metadata/RelationMetadata.ts[R413-414]

+     * @param entity
+     * @param getLazyRelationsPromiseValue

Evidence

PR Compliance ID 4 requires avoiding AI-generated noise and inconsistent style; the PR adds multiple
bare @param lines that provide no additional information (only parameter names).

Rule 4: Remove AI-generated noise
src/metadata/RelationMetadata.ts[410-415]
src/metadata/RelationMetadata.ts[600-605]

Agent prompt

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

## Issue description
Several JSDoc blocks add `@param <name>` entries with no descriptive text. These add low-value commentary and can be considered AI-generated noise / style inconsistency.
## Issue Context
The compliance checklist requires avoiding AI-like slop and inconsistent style. If parameter documentation is desired, it should include meaningful descriptions; otherwise, these tags should be removed.
## Fix Focus Areas
- src/metadata/RelationMetadata.ts[369-372]
- src/metadata/RelationMetadata.ts[385-392]
- src/metadata/RelationMetadata.ts[410-415]
- src/metadata/RelationMetadata.ts[499-506]
- src/metadata/RelationMetadata.ts[549-552]
- src/metadata/RelationMetadata.ts[600-605]
- src/metadata/RelationMetadata.ts[609-614]
- src/metadata/RelationMetadata.ts[632-636]

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

Description

The new lazy-relation branch reads entity[this.propertyName] (including inside an `instanceof
Promise` check), which can invoke the lazy getter and start DB queries unexpectedly, and can also
return a Promise to callers that expect concrete relation values or undefined. This can cause
unexpected queries during initialization/validation and break persistence/transform flows when an
unresolved Promise is returned.

Code

src/metadata/RelationMetadata.ts[R482-491]

+                if (
+                    !Object.getOwnPropertyDescriptor(
+                        entity,
+                        this.propertyName,
+                    )?.get &&
+                    entity[this.propertyName] instanceof Promise
+                ) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

RelationLoader.enableLazyLoad defines a getter for lazy relations that calls
relationLoader.load(...) (DB query) when the property is accessed. EntityMetadata.create applies
this lazy getter to created instances. Then EntityMetadataValidator calls
relation.getEntityValue(entityInstance) during initialization just to detect initialized arrays;
with the new getEntityValue implementation, accessing entity[this.propertyName] can invoke the
getter, triggering unexpected queries and returning a Promise (ignored/not awaited), which can lead
to performance regressions and potential unhandled rejections.

src/metadata/RelationMetadata.ts[468-494]
src/query-builder/RelationLoader.ts[409-477]
src/metadata/EntityMetadata.ts[564-595]
src/metadata-builder/EntityMetadataValidator.ts[200-220]

Agent prompt

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

## Issue description
`RelationMetadata.getEntityValue` now accesses `entity[this.propertyName]` for lazy relations even when `getLazyRelationsPromiseValue` is `false`. If `this.propertyName` is a lazy-loading getter (as installed by `RelationLoader.enableLazyLoad`), that access can trigger a DB query and/or return a Promise into code paths that expect a concrete value or `undefined`.
### Issue Context
- Lazy relations are implemented using `Object.defineProperty(..., { get() { ... relationLoader.load(...) } })`.
- Multiple call sites (e.g. metadata validation and persistence subject building) call `getEntityValue(entity)` with the default flag and do not expect to cause IO or to receive a Promise.
### Fix Focus Areas
- src/metadata/RelationMetadata.ts[475-493]

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

Description

Several new JSDoc @param tags were added without any descriptive text, adding comment noise and
style inconsistency. This conflicts with the requirement to avoid AI-like/low-value commentary
additions.

Code

src/metadata/RelationMetadata.ts[R413-414]

+     * @param entity
+     * @param getLazyRelationsPromiseValue

Evidence

PR Compliance ID 4 requires avoiding AI-generated noise and inconsistent style; the PR adds multiple
bare @param lines that provide no additional information (only parameter names).

Rule 4: Remove AI-generated noise
src/metadata/RelationMetadata.ts[410-415]
src/metadata/RelationMetadata.ts[600-605]

Agent prompt

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

## Issue description
Several JSDoc blocks add `@param <name>` entries with no descriptive text. These add low-value commentary and can be considered AI-generated noise / style inconsistency.
## Issue Context
The compliance checklist requires avoiding AI-like slop and inconsistent style. If parameter documentation is desired, it should include meaningful descriptions; otherwise, these tags should be removed.
## Fix Focus Areas
- src/metadata/RelationMetadata.ts[369-372]
- src/metadata/RelationMetadata.ts[385-392]
- src/metadata/RelationMetadata.ts[410-415]
- src/metadata/RelationMetadata.ts[499-506]
- src/metadata/RelationMetadata.ts[549-552]
- src/metadata/RelationMetadata.ts[600-605]
- src/metadata/RelationMetadata.ts[609-614]
- src/metadata/RelationMetadata.ts[632-636]

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

Description

The PR changes runtime behavior for lazy one-to-many relation value retrieval, which can affect
application behavior. No documentation changes were included to reflect this user-facing behavior
fix.

Code

src/metadata/RelationMetadata.ts[R482-493]

+                const hasGetter =
+                    Object.getOwnPropertyDescriptor(entity, this.propertyName)
+                        ?.get ||
+                    Object.getOwnPropertyDescriptor(
+                        Object.getPrototypeOf(entity),
+                        this.propertyName,
+                    )?.get
+
+                if (hasGetter || entity[this.propertyName] instanceof Promise) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

Compliance requires documentation updates for user-facing changes; the PR modifies lazy relation
handling logic but does not include any accompanying doc update in the provided changes, and the PR
checklist item for docs is left unchecked.

Rule 2: Docs updated for user-facing changes
src/metadata/RelationMetadata.ts[482-493]

Description

Getter detection only checks the entity and its immediate prototype, so a getter higher in the
prototype chain can be missed and inadvertently executed when evaluating entity[propertyName]. This
can cause unexpected side effects (including lazy-load queries) in edge cases with non-trivial
prototype chains (e.g., inheritance/mixins).

Code

src/metadata/RelationMetadata.ts[R482-493]

+                const hasGetter =
+                    Object.getOwnPropertyDescriptor(entity, this.propertyName)
+                        ?.get ||
+                    Object.getOwnPropertyDescriptor(
+                        Object.getPrototypeOf(entity),
+                        this.propertyName,
+                    )?.get
+
+                if (hasGetter || entity[this.propertyName] instanceof Promise) {
+                    return undefined
+                }
+                return entity[this.propertyName]

Evidence

The implementation only inspects one prototype level for an accessor, then may read
entity[this.propertyName]. TypeORM supports inheritance trees, and lazy-load accessors are
installed via Object.defineProperty (including on prototypes), which makes deeper prototype chains
a realistic shape; walking the chain would make the getter-avoidance logic robust.

src/metadata/RelationMetadata.ts[482-493]
src/metadata-builder/EntityMetadataBuilder.ts[446-455]
src/query-builder/RelationLoader.ts[440-477]

Agent prompt

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

## Issue description
`RelationMetadata.getEntityValue()` only checks for an accessor getter on the object itself and its immediate prototype. If a getter exists higher in the prototype chain, the method can still end up evaluating `entity[propertyName]`, invoking the getter and potentially triggering unexpected side effects.
### Issue Context
TypeORM supports inheritance trees and installs lazy relation accessors via `Object.defineProperty` (including on prototypes). A safer approach is to walk the prototype chain when checking for accessors.
### Fix Focus Areas
- src/metadata/RelationMetadata.ts[482-493]

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

Description

Several new JSDoc @param tags were added without any descriptive text, adding comment noise and
style inconsistency. This conflicts with the requirement to avoid AI-like/low-value commentary
additions.

Code

src/metadata/RelationMetadata.ts[R413-414]

+     * @param entity
+     * @param getLazyRelationsPromiseValue

Evidence

PR Compliance ID 4 requires avoiding AI-generated noise and inconsistent style; the PR adds multiple
bare @param lines that provide no additional information (only parameter names).

Rule 4: Remove AI-generated noise
src/metadata/RelationMetadata.ts[410-415]
src/metadata/RelationMetadata.ts[600-605]

Agent prompt

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

## Issue description
Several JSDoc blocks add `@param <name>` entries with no descriptive text. These add low-value commentary and can be considered AI-generated noise / style inconsistency.
## Issue Context
The compliance checklist requires avoiding AI-like slop and inconsistent style. If parameter documentation is desired, it should include meaningful descriptions; otherwise, these tags should be removed.
## Fix Focus Areas
- src/metadata/RelationMetadata.ts[369-372]
- src/metadata/RelationMetadata.ts[385-392]
- src/metadata/RelationMetadata.ts[410-415]
- src/metadata/RelationMetadata.ts[499-506]
- src/metadata/RelationMetadata.ts[549-552]
- src/metadata/RelationMetadata.ts[600-605]
- src/metadata/RelationMetadata.ts[609-614]
- src/metadata/RelationMetadata.ts[632-636]

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