Description

AbstractLogger.setOptions only assigns when this.options is undefined, so subsequent attempts to
change logging (e.g., via DataSource.setOptions() or reuse of the same logger instance) will be
ignored and logging enablement can become incorrect.

Code

src/logger/AbstractLogger.ts[R28-32]

+    setOptions(options: LoggerOptions) {
+        if (this.options === undefined) {
+            this.options = options
+        }
+    }

Evidence

LoggerFactory will call setOptions(options) on an object logger whenever logging is provided,
and DataSource constructs/reconfigures the logger via LoggerFactory using options.logging.
However, AbstractLogger.setOptions is guarded and won’t update if options were previously set;
since AbstractLogger.isLogEnabledFor gates query/error/etc logs based on this.options, the
logger can keep stale gating behavior.

src/logger/AbstractLogger.ts[17-32]
src/logger/AbstractLogger.ts[244-301]
src/logger/LoggerFactory.ts[18-36]
src/data-source/DataSource.ts[141-148]
src/data-source/DataSource.ts[204-212]

Agent prompt

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

## Issue description
`AbstractLogger.setOptions` currently only sets options once (`if (this.options === undefined)`), which prevents later logging configuration changes from taking effect when LoggerFactory calls `setOptions` again.
### Issue Context
- `LoggerFactory.create()` calls `setOptions(options)` on object loggers.
- `DataSource` constructs and can reconfigure its logger via `DataSource.setOptions()`, which re-invokes `LoggerFactory.create()`.
- `AbstractLogger.isLogEnabledFor()` gates logging based on `this.options`.
### Fix Focus Areas
- src/logger/AbstractLogger.ts[23-32]
- test/functional/logger/custom-logger.test.ts[1-61] (optional: add a regression test covering reconfiguration / repeated setOptions)

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

LoggerFactory only calls setOptions when options is truthy, so logging: false is never
propagated to custom logger instances. This can cause unexpected logging behavior when a custom
logger has its own internal default options and expects DataSource’s logging to override it.

Code

src/logger/LoggerFactory.ts[R29-34]

+            if (
+                options &&
+                typeof (logger as Logger).setOptions === "function"
+            ) {
+                ;(logger as Logger).setOptions!(options)
+            }

Evidence

LoggerOptions explicitly allows a boolean value, including false, but LoggerFactory guards
setOptions with options && ..., so it won’t run for false. Since DataSource passes
options.logging directly into LoggerFactory.create, a custom logger instance can miss the
intended logging configuration; for AbstractLogger-based loggers, whether query/error logs run
depends directly on this.options (e.g., this.options === true).

src/logger/LoggerFactory.ts[18-36]
src/logger/LoggerOptions.ts[1-7]
src/data-source/DataSource.ts[141-148]
src/logger/AbstractLogger.ts[242-259]

Agent prompt

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

## Issue description
`LoggerFactory` currently guards the `setOptions` invocation with `options && ...`, which prevents propagating `logging: false` (a valid `LoggerOptions`). This means custom logger instances may not reflect the DataSource’s desired logging configuration.
### Issue Context
- `LoggerOptions` includes `boolean`, so `false` is meaningful.
- `DataSource` passes `options.logging` to `LoggerFactory.create`.
### Fix Focus Areas
- src/logger/LoggerFactory.ts[28-36]
- src/logger/LoggerOptions.ts[1-7]
- src/data-source/DataSource.ts[145-148]

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

The new setOptions invocation uses any casts to bypass typing, which is explicitly disallowed
and can hide real type errors. This introduces style/type-safety noise inconsistent with the rest of
the codebase.

Code

src/logger/LoggerFactory.ts[R28-35]

+        if (ObjectUtils.isObject(logger)) {
+            if (
+                options !== undefined &&
+                typeof (logger as any).setOptions === "function"
+            ) {
+                ;(logger as any).setOptions(options)
+            }
+            return logger as Logger

Evidence

Compliance ID 4 forbids adding any casts to bypass types; the PR introduces `(logger as
any).setOptions checks and invocation when logger` is an object.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[28-35]

Agent prompt

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

## Issue description
`LoggerFactory.create()` uses `(logger as any).setOptions(...)` and `typeof (logger as any).setOptions` which violates the no-`any`/no-noise requirement and can mask type errors.
## Issue Context
The PR introduces `AbstractLogger.setOptions(options: LoggerOptions)` and tries to call it for custom logger instances, but does so via `any` casts.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[28-35]

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

Description

AbstractLogger.setOptions only assigns when this.options is undefined, so subsequent attempts to
change logging (e.g., via DataSource.setOptions() or reuse of the same logger instance) will be
ignored and logging enablement can become incorrect.

Code

src/logger/AbstractLogger.ts[R28-32]

+    setOptions(options: LoggerOptions) {
+        if (this.options === undefined) {
+            this.options = options
+        }
+    }

Evidence

LoggerFactory will call setOptions(options) on an object logger whenever logging is provided,
and DataSource constructs/reconfigures the logger via LoggerFactory using options.logging.
However, AbstractLogger.setOptions is guarded and won’t update if options were previously set;
since AbstractLogger.isLogEnabledFor gates query/error/etc logs based on this.options, the
logger can keep stale gating behavior.

src/logger/AbstractLogger.ts[17-32]
src/logger/AbstractLogger.ts[244-301]
src/logger/LoggerFactory.ts[18-36]
src/data-source/DataSource.ts[141-148]
src/data-source/DataSource.ts[204-212]

Agent prompt

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

## Issue description
`AbstractLogger.setOptions` currently only sets options once (`if (this.options === undefined)`), which prevents later logging configuration changes from taking effect when LoggerFactory calls `setOptions` again.
### Issue Context
- `LoggerFactory.create()` calls `setOptions(options)` on object loggers.
- `DataSource` constructs and can reconfigure its logger via `DataSource.setOptions()`, which re-invokes `LoggerFactory.create()`.
- `AbstractLogger.isLogEnabledFor()` gates logging based on `this.options`.
### Fix Focus Areas
- src/logger/AbstractLogger.ts[23-32]
- test/functional/logger/custom-logger.test.ts[1-61] (optional: add a regression test covering reconfiguration / repeated setOptions)

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

LoggerFactory.create() uses a type assertion to treat any object logger as AbstractLogger and
mutates instance.options without a runtime type guard. This bypasses type safety and can lead to
incorrect behavior when a custom logger object is not an AbstractLogger instance.

Code

src/logger/LoggerFactory.ts[R29-32]

+        if (ObjectUtils.isObject(logger) && options) {
+            const instance = logger as AbstractLogger
+            instance.options = options
+            return instance

Evidence

The compliance checklist forbids type-bypassing casts/style noise; the new code asserts logger is
AbstractLogger and writes to options without verifying the object is actually an
AbstractLogger instance.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[29-33]

Agent prompt

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

## Issue description
`LoggerFactory.create()` currently uses `logger as AbstractLogger` and mutates `instance.options` without confirming the object is an `AbstractLogger`, which bypasses type safety and can mis-handle custom logger objects.
## Issue Context
The factory method accepts `Logger` (interface) instances; not all such objects are guaranteed to extend `AbstractLogger`. Add a runtime check before treating an object as `AbstractLogger`, and ensure custom logger objects that are not `AbstractLogger` are still returned/handled safely.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[29-33]

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

Description

LoggerFactory.create only returns an object logger when options is truthy; if logging is
undefined or false, the provided custom logger instance is discarded and a default
AdvancedConsoleLogger is returned. This breaks the documented configuration pattern (`logger: new
MyCustomLogger() without logging`) and existing tests that pass a logger instance via
createLogger().

Code

src/logger/LoggerFactory.ts[R29-33]

+        if (ObjectUtils.isObject(logger) && options) {
+            const instance = logger as AbstractLogger
+            instance.options = options
+            return instance
+        }

Evidence

LoggerFactory now gates returning a provided logger instance on options being truthy. DataSource
passes this.options.logging as options, which may be undefined or false; docs explicitly show
configuring a custom logger without setting logging; and at least one functional test passes a
logger instance without setting logging. With the new condition, those scenarios skip returning the
custom logger, then fall through the string switch (no cases match for an object) and return the
default AdvancedConsoleLogger.

src/logger/LoggerFactory.ts[19-55]
src/data-source/DataSource.ts[141-148]
src/logger/LoggerOptions.ts[1-7]
docs/docs/advanced-topics/5-logging.md[176-192]
test/functional/repository/find-options/repository-find-options.test.ts[241-252]

Agent prompt

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

## Issue description
`LoggerFactory.create` currently only returns a provided logger instance when `options` is truthy. When `logging` is `undefined` or `false`, the provided logger instance is ignored and the factory returns the default `AdvancedConsoleLogger`, breaking documented usage (`logger: new MyCustomLogger()` without `logging`) and existing tests.
### Issue Context
- `DataSource` passes `options.logging` to `LoggerFactory.create`, which can be `undefined` or `false`.
- `LoggerOptions` explicitly allows `false`.
- The logging docs show specifying a custom logger instance without specifying `logging`.
### Fix Focus Areas
- src/logger/LoggerFactory.ts[19-55]
### Suggested change (high level)
1. If `logger` is an object, always return it as `Logger`.
2. If the object is an `AbstractLogger` and `options !== undefined`, propagate `options` safely:
- Prefer `if (logger instanceof AbstractLogger && options !== undefined && logger.options === undefined) logger.options = options` to avoid clobbering logger instances already configured via their constructor.
- Do **not** cast/mutate arbitrary `Logger` implementations that don’t extend `AbstractLogger`.
3. Consider adding/adjusting a test to cover `createLogger` with `logging` omitted or set to `false` to prevent regressions.

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

The new setOptions invocation uses any casts to bypass typing, which is explicitly disallowed
and can hide real type errors. This introduces style/type-safety noise inconsistent with the rest of
the codebase.

Code

src/logger/LoggerFactory.ts[R28-35]

+        if (ObjectUtils.isObject(logger)) {
+            if (
+                options !== undefined &&
+                typeof (logger as any).setOptions === "function"
+            ) {
+                ;(logger as any).setOptions(options)
+            }
+            return logger as Logger

Evidence

Compliance ID 4 forbids adding any casts to bypass types; the PR introduces `(logger as
any).setOptions checks and invocation when logger` is an object.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[28-35]

Agent prompt

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

## Issue description
`LoggerFactory.create()` uses `(logger as any).setOptions(...)` and `typeof (logger as any).setOptions` which violates the no-`any`/no-noise requirement and can mask type errors.
## Issue Context
The PR introduces `AbstractLogger.setOptions(options: LoggerOptions)` and tries to call it for custom logger instances, but does so via `any` casts.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[28-35]

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

Description

AbstractLogger.setOptions only assigns when this.options is undefined, so subsequent attempts to
change logging (e.g., via DataSource.setOptions() or reuse of the same logger instance) will be
ignored and logging enablement can become incorrect.

Code

src/logger/AbstractLogger.ts[R28-32]

+    setOptions(options: LoggerOptions) {
+        if (this.options === undefined) {
+            this.options = options
+        }
+    }

Evidence

LoggerFactory will call setOptions(options) on an object logger whenever logging is provided,
and DataSource constructs/reconfigures the logger via LoggerFactory using options.logging.
However, AbstractLogger.setOptions is guarded and won’t update if options were previously set;
since AbstractLogger.isLogEnabledFor gates query/error/etc logs based on this.options, the
logger can keep stale gating behavior.

src/logger/AbstractLogger.ts[17-32]
src/logger/AbstractLogger.ts[244-301]
src/logger/LoggerFactory.ts[18-36]
src/data-source/DataSource.ts[141-148]
src/data-source/DataSource.ts[204-212]

Agent prompt

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

## Issue description
`AbstractLogger.setOptions` currently only sets options once (`if (this.options === undefined)`), which prevents later logging configuration changes from taking effect when LoggerFactory calls `setOptions` again.
### Issue Context
- `LoggerFactory.create()` calls `setOptions(options)` on object loggers.
- `DataSource` constructs and can reconfigure its logger via `DataSource.setOptions()`, which re-invokes `LoggerFactory.create()`.
- `AbstractLogger.isLogEnabledFor()` gates logging based on `this.options`.
### Fix Focus Areas
- src/logger/AbstractLogger.ts[23-32]
- test/functional/logger/custom-logger.test.ts[1-61] (optional: add a regression test covering reconfiguration / repeated setOptions)

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

LoggerFactory.create() uses a type assertion to treat any object logger as AbstractLogger and
mutates instance.options without a runtime type guard. This bypasses type safety and can lead to
incorrect behavior when a custom logger object is not an AbstractLogger instance.

Code

src/logger/LoggerFactory.ts[R29-32]

+        if (ObjectUtils.isObject(logger) && options) {
+            const instance = logger as AbstractLogger
+            instance.options = options
+            return instance

Evidence

The compliance checklist forbids type-bypassing casts/style noise; the new code asserts logger is
AbstractLogger and writes to options without verifying the object is actually an
AbstractLogger instance.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[29-33]

Agent prompt

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

## Issue description
`LoggerFactory.create()` currently uses `logger as AbstractLogger` and mutates `instance.options` without confirming th...

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

The new setOptions invocation uses any casts to bypass typing, which is explicitly disallowed
and can hide real type errors. This introduces style/type-safety noise inconsistent with the rest of
the codebase.

Code

src/logger/LoggerFactory.ts[R28-35]

+        if (ObjectUtils.isObject(logger)) {
+            if (
+                options !== undefined &&
+                typeof (logger as any).setOptions === "function"
+            ) {
+                ;(logger as any).setOptions(options)
+            }
+            return logger as Logger

Evidence

Compliance ID 4 forbids adding any casts to bypass types; the PR introduces `(logger as
any).setOptions checks and invocation when logger` is an object.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[28-35]

Agent prompt

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

## Issue description
`LoggerFactory.create()` uses `(logger as any).setOptions(...)` and `typeof (logger as any).setOptions` which violates the no-`any`/no-noise requirement and can mask type errors.
## Issue Context
The PR introduces `AbstractLogger.setOptions(options: LoggerOptions)` and tries to call it for custom logger instances, but does so via `any` casts.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[28-35]

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

Description

AbstractLogger.setOptions only assigns when this.options is undefined, so subsequent attempts to
change logging (e.g., via DataSource.setOptions() or reuse of the same logger instance) will be
ignored and logging enablement can become incorrect.

Code

src/logger/AbstractLogger.ts[R28-32]

+    setOptions(options: LoggerOptions) {
+        if (this.options === undefined) {
+            this.options = options
+        }
+    }

Evidence

LoggerFactory will call setOptions(options) on an object logger whenever logging is provided,
and DataSource constructs/reconfigures the logger via LoggerFactory using options.logging.
However, AbstractLogger.setOptions is guarded and won’t update if options were previously set;
since AbstractLogger.isLogEnabledFor gates query/error/etc logs based on this.options, the
logger can keep stale gating behavior.

src/logger/AbstractLogger.ts[17-32]
src/logger/AbstractLogger.ts[244-301]
src/logger/LoggerFactory.ts[18-36]
src/data-source/DataSource.ts[141-148]
src/data-source/DataSource.ts[204-212]

Agent prompt

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

## Issue description
`AbstractLogger.setOptions` currently only sets options once (`if (this.options === undefined)`), which prevents later logging configuration changes from taking effect when LoggerFactory calls `setOptions` again.
### Issue Context
- `LoggerFactory.create()` calls `setOptions(options)` on object loggers.
- `DataSource` constructs and can reconfigure its logger via `DataSource.setOptions()`, which re-invokes `LoggerFactory.create()`.
- `AbstractLogger.isLogEnabledFor()` gates logging based on `this.options`.
### Fix Focus Areas
- src/logger/AbstractLogger.ts[23-32]
- test/functional/logger/custom-logger.test.ts[1-61] (optional: add a regression test covering reconfiguration / repeated setOptions)

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

LoggerFactory only calls setOptions when options is truthy, so logging: false is never
propagated to custom logger instances. This can cause unexpected logging behavior when a custom
logger has its own internal default options and expects DataSource’s logging to override it.

Code

src/logger/LoggerFactory.ts[R29-34]

+            if (
+                options &&
+                typeof (logger as Logger).setOptions === "function"
+            ) {
+                ;(logger as Logger).setOptions!(options)
+            }

Evidence

LoggerOptions explicitly allows a boolean value, including false, but LoggerFactory guards
setOptions with options && ..., so it won’t run for false. Since DataSource passes
options.logging directly into LoggerFactory.create, a custom logger instance can miss the
intended logging configuration; for AbstractLogger-based loggers, whether query/error logs run
depends directly on this.options (e.g., this.options === true).

src/logger/LoggerFactory.ts[18-36]
src/logger/LoggerOptions.ts[1-7]
src/data-source/DataSource.ts[141-148]
src/logger/AbstractLogger.ts[242-259]

Agent prompt

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

## Issue description
`LoggerFactory` currently guards the `setOptions` invocation with `options && ...`, which prevents propagating `logging: false` (a valid `LoggerOptions`). This means custom logger instances may not reflect the DataSource’s desired logging configuration.
### Issue Context
- `LoggerOptions` includes `boolean`, so `false` is meaningful.
- `DataSource` passes `options.logging` to `LoggerFactory.create`.
### Fix Focus Areas
- src/logger/LoggerFactory.ts[28-36]
- src/logger/LoggerOptions.ts[1-7]
- src/data-source/DataSource.ts[145-148]

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

The new setOptions invocation uses any casts to bypass typing, which is explicitly disallowed
and can hide real type errors. This introduces style/type-safety noise inconsistent with the rest of
the codebase.

Code

src/logger/LoggerFactory.ts[R28-35]

+        if (ObjectUtils.isObject(logger)) {
+            if (
+                options !== undefined &&
+                typeof (logger as any).setOptions === "function"
+            ) {
+                ;(logger as any).setOptions(options)
+            }
+            return logger as Logger

Evidence

Compliance ID 4 forbids adding any casts to bypass types; the PR introduces `(logger as
any).setOptions checks and invocation when logger` is an object.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[28-35]

Agent prompt

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

## Issue description
`LoggerFactory.create()` uses `(logger as any).setOptions(...)` and `typeof (logger as any).setOptions` which violates the no-`any`/no-noise requirement and can mask type errors.
## Issue Context
The PR introduces `AbstractLogger.setOptions(options: LoggerOptions)` and tries to call it for custom logger instances, but does so via `any` casts.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[28-35]

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

Description

AbstractLogger.setOptions only assigns when this.options is undefined, so subsequent attempts to
change logging (e.g., via DataSource.setOptions() or reuse of the same logger instance) will be
ignored and logging enablement can become incorrect.

Code

src/logger/AbstractLogger.ts[R28-32]

+    setOptions(options: LoggerOptions) {
+        if (this.options === undefined) {
+            this.options = options
+        }
+    }

Evidence

LoggerFactory will call setOptions(options) on an object logger whenever logging is provided,
and DataSource constructs/reconfigures the logger via LoggerFactory using options.logging.
However, AbstractLogger.setOptions is guarded and won’t update if options were previously set;
since AbstractLogger.isLogEnabledFor gates query/error/etc logs based on this.options, the
logger can keep stale gating behavior.

src/logger/AbstractLogger.ts[17-32]
src/logger/AbstractLogger.ts[244-301]
src/logger/LoggerFactory.ts[18-36]
src/data-source/DataSource.ts[141-148]
src/data-source/DataSource.ts[204-212]

Agent prompt

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

## Issue description
`AbstractLogger.setOptions` currently only sets options once (`if (this.options === undefined)`), which prevents later logging configuration changes from taking effect when LoggerFactory calls `setOptions` again.
### Issue Context
- `LoggerFactory.create()` calls `setOptions(options)` on object loggers.
- `DataSource` constructs and can reconfigure its logger via `DataSource.setOptions()`, which re-invokes `LoggerFactory.create()`.
- `AbstractLogger.isLogEnabledFor()` gates logging based on `this.options`.
### Fix Focus Areas
- src/logger/AbstractLogger.ts[23-32]
- test/functional/logger/custom-logger.test.ts[1-61] (optional: add a regression test covering reconfiguration / repeated setOptions)

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

LoggerFactory.create mutates a user-supplied logger instance by calling setOptions. If the same
logger instance is reused across multiple DataSources (or reconfigured), the last options applied
can unexpectedly affect all users of that shared instance.

Code

src/logger/LoggerFactory.ts[R30-34]

+        if (ObjectUtils.isObject(logger)) {
+            if (logger instanceof AbstractLogger && options !== undefined) {
+                logger.setOptions(options)
+            }
+            return logger as Logger

Evidence

DataSource passes options.logger (which can be a user-provided object) into
LoggerFactory.create, and the factory now mutates that instance in-place by calling setOptions,
which directly overwrites AbstractLogger.options. This creates cross-DataSource coupling when a
single logger object is shared.

src/data-source/DataSource.ts[141-148]
src/logger/LoggerFactory.ts[30-35]
src/logger/AbstractLogger.ts[17-30]

Agent prompt

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

## Issue description
`LoggerFactory.create()` calls `setOptions()` on a user-provided logger instance. If consumers reuse the same logger object across multiple `DataSource`s with different `logging` options, the last `DataSource` to initialize (or update) will overwrite the options for all, producing confusing/incorrect logging.
### Issue Context
- `DataSource` passes `options.logger` into `LoggerFactory.create`.
- The factory now mutates the instance via `setOptions`, which overwrites the shared instance state.
### Fix Focus Areas
- src/logger/LoggerFactory.ts[30-35]
- src/logger/AbstractLogger.ts[17-30]
- src/data-source/DataSource.ts[141-148]
### Suggested direction
Option A (behavioral mitigation): If `logger` is an object and supports `setOptions`, return a *wrapper* logger per `DataSource` that calls `logger.setOptions(options)` at the start of each log method, then delegates to the underlying logger. This reduces persistent cross-DataSource coupling while keeping the fix for #10174.
Option B (doc/API contract): Explicitly document (and potentially assert in dev) that `options.logger` must be a fresh instance per `DataSource` if it is stateful (like `AbstractLogger`).

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

Description

Logger.ts now imports LoggerOptions, while LoggerOptions.ts imports LogLevel from
Logger.ts, creating a module cycle. This is likely type-only, but using explicit import type
avoids potential runtime requires in some TS build configurations and clarifies intent.

Code

src/logger/Logger.ts[1]

+import { LoggerOptions } from "./LoggerOptions"

Evidence

The PR introduced an import from Logger to LoggerOptions in Logger.ts, while
LoggerOptions.ts already imports from Logger.ts. Even if this is commonly elided as type-only,
it’s a real circular dependency at the module level and can be made unambiguous via import type.

src/logger/Logger.ts[1-2]
src/logger/LoggerOptions.ts[1-2]

Agent prompt

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

## Issue description
There is a circular module dependency between `src/logger/Logger.ts` and `src/logger/LoggerOptions.ts` created by mutual imports.
### Issue Context
Even when imports are used only for types, some TS configurations (or future refactors) can emit them, and the cycle is avoidable.
### Fix Focus Areas
- src/logger/Logger.ts[1-2]
- src/logger/LoggerOptions.ts[1-2]

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

Description

The new functional test introduces an explicit any type in .filter((call: any) => ...), which is
a type-safety bypass. This violates the requirement to avoid AI-like noise such as any casts to
bypass type issues.

Code

test/functional/logger/custom-logger.test.ts[58]

+                    .filter((call: any) => call.args[0] === "query")

Evidence

The compliance checklist forbids introducing any casts to bypass typing. The added test uses
(call: any) even though Sinon call types can be inferred or typed more precisely.

Rule 4: Remove AI-generated noise
test/functional/logger/custom-logger.test.ts[56-59]

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 test introduces an explicit `any` cast in a filter callback, bypassing type safety.
## Issue Context
Rule 4 requires avoiding `any` casts added to silence or bypass TypeScript typing issues.
## Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[56-59] ևս

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

Description

LoggerFactory.create mutates a user-supplied logger instance by calling setOptions. If the same
logger instance is reused across multiple DataSources (or reconfigured), the last options applied
can unexpectedly affect all users of that shared instance.

Code

src/logger/LoggerFactory.ts[R30-34]

+        if (ObjectUtils.isObject(logger)) {
+            if (logger instanceof AbstractLogger && options !== undefined) {
+                logger.setOptions(options)
+            }
+            return logger as Logger

Evidence

DataSource passes options.logger (which can be a user-provided object) into
LoggerFactory.create, and the factory now mutates that instance in-place by calling setOptions,
which directly overwrites AbstractLogger.options. This creates cross-DataSource coupling when a
single logger object is shared.

src/data-source/DataSource.ts[141-148]
src/logger/LoggerFactory.ts[30-35]
[src/logger/AbstractLogger.ts[17-30]](https://github.com/typeorm/typeorm/blob/9aafcafb04717069e767b01cba172b00caa38ea...

Description

The new setOptions invocation uses any casts to bypass typing, which is explicitly disallowed
and can hide real type errors. This introduces style/type-safety noise inconsistent with the rest of
the codebase.

Code

src/logger/LoggerFactory.ts[R28-35]

+        if (ObjectUtils.isObject(logger)) {
+            if (
+                options !== undefined &&
+                typeof (logger as any).setOptions === "function"
+            ) {
+                ;(logger as any).setOptions(options)
+            }
+            return logger as Logger

Evidence

Compliance ID 4 forbids adding any casts to bypass types; the PR introduces `(logger as
any).setOptions checks and invocation when logger` is an object.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[28-35]

Agent prompt

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

## Issue description
`LoggerFactory.create()` uses `(logger as any).setOptions(...)` and `typeof (logger as any).setOptions` which violates the no-`any`/no-noise requirement and can mask type errors.
## Issue Context
The PR introduces `AbstractLogger.setOptions(options: LoggerOptions)` and tries to call it for custom logger instances, but does so via `any` casts.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[28-35]

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

Description

AbstractLogger.setOptions only assigns when this.options is undefined, so subsequent attempts to
change logging (e.g., via DataSource.setOptions() or reuse of the same logger instance) will be
ignored and logging enablement can become incorrect.

Code

src/logger/AbstractLogger.ts[R28-32]

+    setOptions(options: LoggerOptions) {
+        if (this.options === undefined) {
+            this.options = options
+        }
+    }

Evidence

LoggerFactory will call setOptions(options) on an object logger whenever logging is provided,
and DataSource constructs/reconfigures the logger via LoggerFactory using options.logging.
However, AbstractLogger.setOptions is guarded and won’t update if options were previously set;
since AbstractLogger.isLogEnabledFor gates query/error/etc logs based on this.options, the
logger can keep stale gating behavior.

src/logger/AbstractLogger.ts[17-32]
src/logger/AbstractLogger.ts[244-301]
src/logger/LoggerFactory.ts[18-36]
src/data-source/DataSource.ts[141-148]
src/data-source/DataSource.ts[204-212]

Agent prompt

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

## Issue description
`AbstractLogger.setOptions` currently only sets options once (`if (this.options === undefined)`), which prevents later logging configuration changes from taking effect when LoggerFactory calls `setOptions` again.
### Issue Context
- `LoggerFactory.create()` calls `setOptions(options)` on object loggers.
- `DataSource` constructs and can reconfigure its logger via `DataSource.setOptions()`, which re-invokes `LoggerFactory.create()`.
- `AbstractLogger.isLogEnabledFor()` gates logging based on `this.options`.
### Fix Focus Areas
- src/logger/AbstractLogger.ts[23-32]
- test/functional/logger/custom-logger.test.ts[1-61] (optional: add a regression test covering reconfiguration / repeated setOptions)

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

LoggerFactory only calls setOptions when options is truthy, so logging: false is never
propagated to custom logger instances. This can cause unexpected logging behavior when a custom
logger has its own internal default options and expects DataSource’s logging to override it.

Code

src/logger/LoggerFactory.ts[R29-34]

+            if (
+                options &&
+                typeof (logger as Logger).setOptions === "function"
+            ) {
+                ;(logger as Logger).setOptions!(options)
+            }

Evidence

LoggerOptions explicitly allows a boolean value, including false, but LoggerFactory guards
setOptions with options && ..., so it won’t run for false. Since DataSource passes
options.logging directly into LoggerFactory.create, a custom logger instance can miss the
intended logging configuration; for AbstractLogger-based loggers, whether query/error logs run
depends directly on this.options (e.g., this.options === true).

src/logger/LoggerFactory.ts[18-36]
src/logger/LoggerOptions.ts[1-7]
src/data-source/DataSource.ts[141-148]
src/logger/AbstractLogger.ts[242-259]

Agent prompt

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

## Issue description
`LoggerFactory` currently guards the `setOptions` invocation with `options && ...`, which prevents propagating `logging: false` (a valid `LoggerOptions`). This means custom logger instances may not reflect the DataSource’s desired logging configuration.
### Issue Context
- `LoggerOptions` includes `boolean`, so `false` is meaningful.
- `DataSource` passes `options.logging` to `LoggerFactory.create`.
### Fix Focus Areas
- src/logger/LoggerFactory.ts[28-36]
- src/logger/LoggerOptions.ts[1-7]
- src/data-source/DataSource.ts[145-148]

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

The new setOptions invocation uses any casts to bypass typing, which is explicitly disallowed
and can hide real type errors. This introduces style/type-safety noise inconsistent with the rest of
the codebase.

Code

src/logger/LoggerFactory.ts[R28-35]

+        if (ObjectUtils.isObject(logger)) {
+            if (
+                options !== undefined &&
+                typeof (logger as any).setOptions === "function"
+            ) {
+                ;(logger as any).setOptions(options)
+            }
+            return logger as Logger

Evidence

Compliance ID 4 forbids adding any casts to bypass types; the PR introduces `(logger as
any).setOptions checks and invocation when logger` is an object.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[28-35]

Agent prompt

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

## Issue description
`LoggerFactory.create()` uses `(logger as any).setOptions(...)` and `typeof (logger as any).setOptions` which violates the no-`any`/no-noise requirement and can mask type errors.
## Issue Context
The PR introduces `AbstractLogger.setOptions(options: LoggerOptions)` and tries to call it for custom logger instances, but does so via `any` casts.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[28-35]

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

Description

AbstractLogger.setOptions only assigns when this.options is undefined, so subsequent attempts to
change logging (e.g., via DataSource.setOptions() or reuse of the same logger instance) will be
ignored and logging enablement can become incorrect.

Code

src/logger/AbstractLogger.ts[R28-32]

+    setOptions(options: LoggerOptions) {
+        if (this.options === undefined) {
+            this.options = options
+        }
+    }

Evidence

LoggerFactory will call setOptions(options) on an object logger whenever logging is provided,
and DataSource constructs/reconfigures the logger via LoggerFactory using options.logging.
However, AbstractLogger.setOptions is guarded and won’t update if options were previously set;
since AbstractLogger.isLogEnabledFor gates query/error/etc logs based on this.options, the
logger can keep stale gating behavior.

src/logger/AbstractLogger.ts[17-32]
src/logger/AbstractLogger.ts[244-301]
src/logger/LoggerFactory.ts[18-36]
src/data-source/DataSource.ts[141-148]
src/data-source/DataSource.ts[204-212]

Agent prompt

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

## Issue description
`AbstractLogger.setOptions` currently only sets options once (`if (this.options === undefined)`), which prevents later logging configuration changes from taking effect when LoggerFactory calls `setOptions` again.
### Issue Context
- `LoggerFactory.create()` calls `setOptions(options)` on object loggers.
- `DataSource` constructs and can reconfigure its logger via `DataSource.setOptions()`, which re-invokes `LoggerFactory.create()`.
- `AbstractLogger.isLogEnabledFor()` gates logging based on `this.options`.
### Fix Focus Areas
- src/logger/AbstractLogger.ts[23-32]
- test/functional/logger/custom-logger.test.ts[1-61] (optional: add a regression test covering reconfiguration / repeated setOptions)

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

LoggerFactory.create() uses a type assertion to treat any object logger as AbstractLogger and
mutates instance.options without a runtime type guard. This bypasses type safety and can lead to
incorrect behavior when a custom logger object is not an AbstractLogger instance.

Code

src/logger/LoggerFactory.ts[R29-32]

+        if (ObjectUtils.isObject(logger) && options) {
+            const instance = logger as AbstractLogger
+            instance.options = options
+            return instance

Evidence

The compliance checklist forbids type-bypassing casts/style noise; the new code asserts logger is
AbstractLogger and writes to options without verifying the object is actually an
AbstractLogger instance.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[29-33]

Agent prompt

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

## Issue description
`LoggerFactory.create()` currently uses `logger as AbstractLogger` and mutates `instance.options` without confirming the object is an `AbstractLogger`, which bypasses type safety and can mis-handle custom logger objects.
## Issue Context
The factory method accepts `Logger` (interface) instances; not all such objects are guaranteed to extend `AbstractLogger`. Add a runtime check before treating an object as `AbstractLogger`, and ensure custom logger objects that are not `AbstractLogger` are still returned/handled safely.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[29-33]

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

Description

LoggerFactory.create only returns an object logger when options is truthy; if logging is
undefined or false, the provided custom logger instance is discarded and a default
AdvancedConsoleLogger is returned. This breaks the documented configuration pattern (`logger: new
MyCustomLogger() without logging`) and existing tests that pass a logger instance via
createLogger().

Code

src/logger/LoggerFactory.ts[R29-33]

+        if (ObjectUtils.isObject(logger) && options) {
+            const instance = logger as AbstractLogger
+            instance.options = options
+            return instance
+        }

Evidence

LoggerFactory now gates returning a provided logger instance on options being truthy. DataSource
passes this.options.logging as options, which may be undefined or false; docs explicitly show
configuring a custom logger without setting logging; and at least one functional test passes a
logger instance without setting logging. With the new condition, those scenarios skip returning the
custom logger, then fall through the string switch (no cases match for an object) and return the
default AdvancedConsoleLogger.

src/logger/LoggerFactory.ts[19-55]
src/data-source/DataSource.ts[141-148]
src/logger/LoggerOptions.ts[1-7]
docs/docs/advanced-topics/5-logging.md[176-192]
test/functional/repository/find-options/repository-find-options.test.ts[241-252]

Agent prompt

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

## Issue description
`LoggerFactory.create` currently only returns a provided logger instance when `options` is truthy. When `logging` is `undefined` or `false`, the provided logger instance is ignored and the factory returns the default `AdvancedConsoleLogger`, breaking documented usage (`logger: new MyCustomLogger()` without `logging`) and existing tests.
### Issue Context
- `DataSource` passes `options.logging` to `LoggerFactory.create`, which can be `undefined` or `false`.
- `LoggerOptions` explicitly allows `false`.
- The logging docs show specifying a custom logger instance without specifying `logging`.
### Fix Focus Areas
- src/logger/LoggerFactory.ts[19-55]
### Suggested change (high level)
1. If `logger` is an object, always return it as `Logger`.
2. If the object is an `AbstractLogger` and `options !== undefined`, propagate `options` safely:
- Prefer `if (logger instanceof AbstractLogger && options !== undefined && logger.options === undefined) logger.options = options` to avoid clobbering logger instances already configured via their constructor.
- Do **not** cast/mutate arbitrary `Logger` implementations that don’t extend `AbstractLogger`.
3. Consider adding/adjusting a test to cover `createLogger` with `logging` omitted or set to `false` to prevent regressions.

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

Description

The new test runs per-DataSource checks in parallel while sharing a single fakeLog and resetting
its history inside each parallel task, which can drop log calls and make the test nondeterministic.

Code

test/functional/logger/custom-logger.test.ts[R46-61]

+    it("should invoke custom logger writeLog for queries when logging is enabled (issue #10174)", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                fakeLog.resetHistory()
+
+                const repository = dataSource.getRepository(Post)
+                await repository.save({ title: "test" })
+                await repository.find()
+
+                expect(fakeLog.called).to.be.true
+                const queryLogs = fakeLog
+                    .getCalls()
+                    .filter((call: any) => call.args[0] === "query")
+                expect(queryLogs.length).to.be.greaterThan(0)
+            }),
+        ))

Evidence

Promise.all(dataSources.map(...)) executes concurrently, but fakeLog is shared and
resetHistory() is called inside each async task; resets from one task can erase calls produced by
another task before assertions run.

test/functional/logger/custom-logger.test.ts[12-61]

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 test uses a shared `sinon.fake()` (`fakeLog`) but runs multiple DataSources in parallel via `Promise.all(...)` and calls `fakeLog.resetHistory()` inside each async task. This can erase log calls from other tasks and cause intermittent CI failures.
### Issue Context
`createTestingConnections` often returns multiple DataSources (per driver). The test currently parallelizes validation across them.
### Fix Focus Areas
- test/functional/logger/custom-logger.test.ts[46-61]
### Suggested direction
Option A (simplest): replace `Promise.all(dataSources.map(async ...))` with a sequential loop:
- `for (const dataSource of dataSources) { fakeLog.resetHistory(); ... await ...; expect(...) }`
Option B: create a distinct fake per DataSource by having `CustomLogger` accept a callback/fake in its constructor and using `createLogger` to create per-connection instances with isolated fakes.

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

Description

The new setOptions invocation uses any casts to bypass typing, which is explicitly disallowed
and can hide real type errors. This introduces style/type-safety noise inconsistent with the rest of
the codebase.

Code

src/logger/LoggerFactory.ts[R28-35]

+        if (ObjectUtils.isObject(logger)) {
+            if (
+                options !== undefined &&
+                typeof (logger as any).setOptions === "function"
+            ) {
+                ;(logger as any).setOptions(options)
+            }
+            return logger as Logger

Evidence

Compliance ID 4 forbids adding any casts to bypass types; the PR introduces `(logger as
any).setOptions checks and invocation when logger` is an object.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[28-35]

Agent prompt

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

## Issue description
`LoggerFactory.create()` uses `(logger as any).setOptions(...)` and `typeof (logger as any).setOptions` which violates the no-`any`/no-noise requirement and can mask type errors.
## Issue Context
The PR introduces `AbstractLogger.setOptions(options: LoggerOptions)` and tries to call it for custom logger instances, but does so via `any` casts.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[28-35]

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

Description

AbstractLogger.setOptions only assigns when this.options is undefined, so subsequent attempts to
change logging (e.g., via DataSource.setOptions() or reuse of the same logger instance) will be
ignored and logging enablement can become incorrect.

Code

src/logger/AbstractLogger.ts[R28-32]

+    setOptions(options: LoggerOptions) {
+        if (this.options === undefined) {
+            this.options = options
+        }
+    }

Evidence

LoggerFactory will call setOptions(options) on an object logger whenever logging is provided,
and DataSource constructs/reconfigures the logger via LoggerFactory using options.logging.
However, AbstractLogger.setOptions is guarded and won’t update if options were previously set;
since AbstractLogger.isLogEnabledFor gates query/error/etc logs based on this.options, the
logger can keep stale gating behavior.

src/logger/AbstractLogger.ts[17-32]
src/logger/AbstractLogger.ts[244-301]
src/logger/LoggerFactory.ts[18-36]
src/data-source/DataSource.ts[141-148]
src/data-source/DataSource.ts[204-212]

Agent prompt

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

## Issue description
`AbstractLogger.setOptions` currently only sets options once (`if (this.options === undefined)`), which prevents later logging configuration changes from taking effect when LoggerFactory calls `setOptions` again.
### Issue Context
- `LoggerFactory.create()` calls `setOptions(options)` on object loggers.
- `DataSource` constructs and can reconfigure its logger via `DataSource.setOptions()`, which re-invokes `LoggerFactory.create()`.
- `AbstractLogger.isLogEnabledFor()` gates logging based on `this.options`.
### Fix Focus Areas
- src/logger/AbstractLogger.ts[23-32]
- test/functional/logger/custom-logger.test.ts[1-61] (optional: add a regression test covering reconfiguration / repeated setOptions)

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

Description

A new public AbstractLogger.setOptions() API is added and invoked by LoggerFactory, changing how
custom loggers receive LoggerOptions. The logging documentation for custom loggers is not updated
to describe this behavior, risking user confusion and misuse.

Code

src/logger/AbstractLogger.ts[R23-30]

+    /**
+     * Sets logger options. Used to pass DataSource logging options
+     * to custom logger instances.
+     * @param options
+     */
+    setOptions(options: LoggerOptions) {
+        this.options = options
+    }

Evidence

Compliance requires docs updates for user-facing changes. This PR adds a new public method
setOptions() and calls it when a custom logger is supplied, but the logging docs section about
custom loggers does not mention this options propagation behavior.

Rule 2: Docs updated for user-facing changes
src/logger/AbstractLogger.ts[23-30]
src/logger/LoggerFactory.ts[30-33]
docs/docs/advanced-topics/5-logging.md[102-114]
docs/docs/advanced-topics/5-logging.md[176-192]

Agent prompt

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

## Issue description
A new public API (`AbstractLogger.setOptions`) is introduced and used to pass `LoggerOptions` into custom loggers, but the user documentation for custom loggers does not explain this behavior.
## Issue Context
Users following the current "Using custom logger" docs may not realize options are now injected into `AbstractLogger` subclasses when providing `logger: new MyCustomLogger()`, and how to access them.
## Fix Focus Areas
- docs/docs/advanced-topics/5-logging.md[102-206]
- src/logger/AbstractLogger.ts[23-30]
- src/logger/LoggerFactory.ts[30-35]

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

...

Description

The new setOptions invocation uses any casts to bypass typing, which is explicitly disallowed
and can hide real type errors. This introduces style/type-safety noise inconsistent with the rest of
the codebase.

Code

src/logger/LoggerFactory.ts[R28-35]

+        if (ObjectUtils.isObject(logger)) {
+            if (
+                options !== undefined &&
+                typeof (logger as any).setOptions === "function"
+            ) {
+                ;(logger as any).setOptions(options)
+            }
+            return logger as Logger

Evidence

Compliance ID 4 forbids adding any casts to bypass types; the PR introduces `(logger as
any).setOptions checks and invocation when logger` is an object.

Rule 4: Remove AI-generated noise
src/logger/LoggerFactory.ts[28-35]

Agent prompt

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

## Issue description
`LoggerFactory.create()` uses `(logger as any).setOptions(...)` and `typeof (logger as any).setOptions` which violates the no-`any`/no-noise requirement and can mask type errors.
## Issue Context
The PR introduces `AbstractLogger.setOptions(options: LoggerOptions)` and tries to call it for custom logger instances, but does so via `any` casts.
## Fix Focus Areas
- src/logger/LoggerFactory.ts[28-35]

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

Description

AbstractLogger.setOptions only assigns when this.options is undefined, so subsequent attempts to
change logging (e.g., via DataSource.setOptions() or reuse of the same logger instance) will be
ignored and logging enablement can become incorrect.

Code

src/logger/AbstractLogger.ts[R28-32]

+    setOptions(options: LoggerOptions) {
+        if (this.options === undefined) {
+            this.options = options
+        }
+    }

Evidence

LoggerFactory will call setOptions(options) on an object logger whenever logging is provided,
and DataSource constructs/reconfigures the logger via LoggerFactory using options.logging.
However, AbstractLogger.setOptions is guarded and won’t update if options were previously set;
since AbstractLogger.isLogEnabledFor gates query/error/etc logs based on this.options, the
logger can keep stale gating behavior.

src/logger/AbstractLogger.ts[17-32]
src/logger/AbstractLogger.ts[244-301]
src/logger/LoggerFactory.ts[18-36]
src/data-source/DataSource.ts[141-148]
src/data-source/DataSource.ts[204-212]