fix(query-builder): skip eager relation query when the main query already joins it - #12777

Description

isRelationHydratedByJoin() always disqualifies a join when the related entity has eager relations,
even when loadEagerRelations is explicitly false (so the separate load would not include those eager
relations either). This prevents the new skip logic from working in that configuration and can keep
running redundant relation queries under relationLoadStrategy:"query".

Code

src/query-builder/SelectQueryBuilder.ts[R3462-3463]

+        if (relation.inverseEntityMetadata.eagerRelations.length > 0)
+            return false

Evidence

The new method unconditionally rejects joins when the target has eager relations, but the codebase
shows eager loading is skipped entirely when loadEagerRelations === false, and that flag is
propagated into the separate relation-load query path. Therefore, the eager-relations disqualifier
should be conditional on eager loading actually being enabled.

src/query-builder/SelectQueryBuilder.ts[3459-3464]
src/query-builder/SelectQueryBuilder.ts[3727-3789]
src/query-builder/RelationLoader.ts[433-451]

Agent prompt

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

### Issue description
`isRelationHydratedByJoin()` returns `false` whenever `relation.inverseEntityMetadata.eagerRelations.length > 0`, but when `loadEagerRelations === false` the separate relation-load query path will *not* load those eager relations. This makes the new join-hydration equivalence check unnecessarily strict and leaves redundant relation queries in place.

### Issue Context
The separate relation-load query builder propagates `loadEagerRelations` into the child query builder; `RelationLoader` and `applyFindOptions` already honor `loadEagerRelations === false`.

### Fix Focus Areas
- src/query-builder/SelectQueryBuilder.ts[3462-3463]

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

Description

isRelationHydratedByJoin() requires !join.condition, but join() automatically injects a
soft-delete ON predicate (alias.deletedAt IS NULL) for joined entities with a deleteDateColumn
when withDeleted is not enabled. This makes otherwise-unrestricted left joins on soft-deletable
relations never qualify, so the relation can still be loaded twice under
relationLoadStrategy:"query".

Code

src/query-builder/SelectQueryBuilder.ts[R3485-3488]

+                join.entityOrProperty === relationPath &&
+                join.direction === "LEFT" &&
+                !join.condition &&
+                join.mapToProperty === undefined &&

Evidence

The new equivalence check disqualifies any join with join.condition, but the join builder itself
auto-populates joinAttribute.condition with a delete-date predicate for soft-deleted entities.
That means a plain leftJoinAndSelect() can still have a non-empty condition and thus will never be
considered ‘already hydrated’.

src/query-builder/SelectQueryBuilder.ts[3482-3494]
src/query-builder/SelectQueryBuilder.ts[2080-2165]

Agent prompt

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

### Issue description
`isRelationHydratedByJoin()` rejects any join that has a `join.condition`. However, `SelectQueryBuilder.join()` can automatically set `joinAttribute.condition` to the soft-delete predicate (e.g. `${aliasName}.${deleteDateColumn.propertyName} IS NULL`) even when the caller did not supply an ON condition. This blocks the new optimization for soft-deletable related entities, leaving redundant relation-load queries.

### Issue Context
This only applies when the joined entity has a `deleteDateColumn` and the query is *not* `withDeleted`.

### Fix Focus Areas
- src/query-builder/SelectQueryBuilder.ts[3485-3488]
- src/query-builder/SelectQueryBuilder.ts[2131-2139]

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

💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗