Description

The PR removes support for legacy Redis clients (v3/v4) but no documentation updates are included.
This can break existing users without guidance on required Redis client versions and migration
steps.

Code

src/cache/RedisQueryResultCache.ts[R59-62]

+            this.client = this.redis.createClient(clientOptions)

           if (
               typeof this.dataSource.options.cache === "object" &&

Evidence

The checklist requires docs to be updated for user-facing changes. The PR description states legacy
Redis client support is being removed, and the code changes remove legacy-version handling and now
always uses the modern connect flow, but there are no accompanying doc changes in this PR diff.

Rule 2: Docs updated for user-facing changes
src/cache/RedisQueryResultCache.ts[59-70]

Agent prompt

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

## Issue description
This change removes support for legacy `redis` v3/v4 clients, but the PR does not include documentation updates to reflect the new minimum supported versions and any migration steps.
## Issue Context
Users relying on older Redis client versions may experience runtime failures or type/API mismatches after upgrading.
## Fix Focus Areas
- src/cache/RedisQueryResultCache.ts[59-70]

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

Description

RedisQueryResultCache now imports types from optional peer dependencies (and ioredis as a value
import), which forces TypeScript to resolve those modules during build and leaks those types into
generated .d.ts. Because DataSource imports the cache factory, this can break TypeORM
compilation/consumption for users who do not have redis/ioredis installed (even if cache is
disabled).

Code

src/cache/RedisQueryResultCache.ts[R7-8]

+import Redis, { Cluster } from "ioredis"
+import { RedisClientType } from "redis"

Evidence

RedisQueryResultCache adds top-level imports from optional packages and uses them in an exported
class property type. TypeORM emits declarations (tsconfig.json), so the compiler must resolve these
modules/types, and consumers may also need these deps just to typecheck. This violates the existing
optional-peer-dependency/dynamic-load pattern (PlatformTools.load) and is reachable via common
entrypoints because DataSource imports QueryResultCacheFactory which imports RedisQueryResultCache.

src/cache/RedisQueryResultCache.ts[1-32]
src/cache/RedisQueryResultCache.ts[212-227]
src/platform/PlatformTools.ts[106-114]
src/cache/QueryResultCacheFactory.ts[1-45]
src/data-source/DataSource.ts[31-35]
src/data-source/DataSource.ts[141-156]
package.json[109-168]
package.json[169-185]
package.json[186-222]
tsconfig.json[1-27]

Agent prompt

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

## Issue description
`RedisQueryResultCache` introduces top-level imports from `ioredis` and `redis` types, which breaks TypeORM’s optional peer dependency model and can cause `tsc`/declaration generation to fail when `ioredis` isn’t installed. It also leaks those types into the exported class declaration, forcing downstream typecheckers to have those packages installed.
### Issue Context
- TypeORM uses `PlatformTools.load()` to dynamically `require()` optional dependencies.
- `DataSource` imports `QueryResultCacheFactory`, which imports `RedisQueryResultCache`, so any eager import in that file is effectively part of the common entry path.
- `tsconfig.json` enables `declaration: true`, so any referenced external types must be resolvable and may appear in `.d.ts`.
### Fix Focus Areas
- src/cache/RedisQueryResultCache.ts[1-32]
- src/cache/RedisQueryResultCache.ts[23-31]
- src/cache/RedisQueryResultCache.ts[212-227]
### Suggested approach
- Remove `import Redis, { Cluster } from "ioredis"` and `import { RedisClientType } from "redis"`.
- Change `protected client` back to `any`/`unknown`, **or** define a small local structural interface that covers only the methods TypeORM calls (`connect`, `quit`, `get`, `set`, `del`, `flushDb/flushdb`).
- Keep using `PlatformTools.load()` for runtime module loading.
- Ensure generated `.d.ts` does not reference `ioredis`/`redis` types.

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

Description

The unit tests still invoke the removed detectRedisVersion()/redisMajorVersion logic via (cache as
any), which will now throw at runtime and fail CI (tests run from compiled output).

Code

src/cache/RedisQueryResultCache.ts[L313-341]

-    /**
-     * Detects the Redis package version by reading the installed package.json
-     * and sets the appropriate API version (3 for callback-based, 5 for Promise-based).
-     */
-    private detectRedisVersion(): void {
-        if (this.clientType !== "redis") return
-        const version = PlatformTools.readPackageVersion("redis")
-        const major = parseInt(version.split(".")[0], 10)
-        if (isNaN(major)) {
-            throw new TypeORMError(`Invalid Redis version format: ${version}`)
-        }
-        if (major <= 4) {
-            // Redis 3/4 uses callback-based API
-            this.redisMajorVersion = 3
-        } else {
-            // Redis 5+ uses Promise-based API
-            this.redisMajorVersion = 5
-        }
-    }
-
-    /**
-     * Checks if Redis version is 5.x or higher
-     */
-    private isRedis5OrHigher(): boolean {
-        if (this.clientType !== "redis") return false
-        return (
-            this.redisMajorVersion !== undefined && this.redisMajorVersion >= 5
-        )
-    }

Evidence

The test suite explicitly calls detectRedisVersion() and asserts redisMajorVersion. The updated
RedisQueryResultCache no longer defines those members (class ends after loadRedis). Since mocha runs
compiled tests, this will fail at runtime with `TypeError: cache.detectRedisVersion is not a
function`.

test/unit/cache/redis-query-result-cache.test.ts[8-106]
src/cache/RedisQueryResultCache.ts[200-228]
.mocharc.json[6-9]

Agent prompt

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

## Issue description
Unit tests still rely on `detectRedisVersion()` and `redisMajorVersion`, which were removed. These tests will now fail at runtime.
### Issue Context
`RedisQueryResultCache` was simplified and no longer has version detection. The existing unit test suite is now out of sync.
### Fix Focus Areas
- test/unit/cache/redis-query-result-cache.test.ts[8-106]
- src/cache/RedisQueryResultCache.ts[1-228]
### Suggested approach
- Remove the `detectRedisVersion` describe block entirely, or rewrite it to test the new behavior.
- Add targeted tests for:
- `loadRedis()` throwing a helpful error when the selected client type isn’t installed (stubbing `PlatformTools.load` to throw).
- `connect()` path for `clientType === "redis"` calling `.connect()` on the created client.

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

Description

disconnect() no longer clears the stored client reference after quit(), increasing risk of
accidental use-after-disconnect and making lifecycle management less robust.

Code

src/cache/RedisQueryResultCache.ts[R114-115]

+        await this.client.quit()
   }

Evidence

The current disconnect implementation only calls quit(). There is no state reset, so subsequent
operations can still access a stale client reference.

src/cache/RedisQueryResultCache.ts[110-115]

Agent prompt

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

## Issue description
`disconnect()` does not clear `this.client` after quitting, leaving a stale reference and making use-after-disconnect more likely.
### Issue Context
Previous implementation cleared the client reference; the new simplified version does not.
### Fix Focus Areas
- src/cache/RedisQueryResultCache.ts[110-115]
- src/cache/RedisQueryResultCache.ts[23-27]
### Suggested approach
- Change `protected client` to allow `undefined` and set `this.client = undefined` after `await this.client.quit()`.
- Optionally add guards in public methods (get/store/clear/remove) to throw a clear error if `client` is undefined.

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

Description

The RedisQueryResultCache unit tests are now skipped entirely, removing coverage for cache behavior
during a risky refactor. This increases the likelihood of shipping runtime regressions in
redis/ioredis integrations.

Code

test/unit/cache/redis-query-result-cache.test.ts[8]

+describe.skip("RedisQueryResultCache", () => {

Evidence

The test suite is explicitly disabled via describe.skip, so CI will not exercise any
RedisQueryResultCache behavior or validate the refactor.

test/unit/cache/redis-query-result-cache.test.ts[1-10]

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 RedisQueryResultCache unit suite is fully skipped, and the remaining tests target a removed method (`detectRedisVersion`). This leaves the refactor untested.
### Issue Context
This PR changes command invocation patterns and dependency loading behavior; tests should validate client-specific method signatures and optional dependency behavior.
### Fix Focus Areas
- test/unit/cache/redis-query-result-cache.test.ts[1-107]
- src/cache/RedisQueryResultCache.ts[52-108]
- src/cache/RedisQueryResultCache.ts[156-168]
- src/cache/RedisQueryResultCache.ts[208-210]
### What to change
- Replace `describe.skip(...)` with `describe(...)`.
- Remove/update the `detectRedisVersion` tests.
- Add unit tests that stub the underlying client and assert:
- For `clientType: "redis"`, `storeInCache` uses the redis-v5-compatible `set` signature.
- For `clientType: "ioredis"` / `"ioredis/cluster"`, `storeInCache` uses the expected ioredis signature.
- `deleteKey` calls `del` with the correct argument shape.

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

Description

This PR removes legacy Redis v3/v4 client support, which is a user-facing behavior/API compatibility
change. The PR indicates documentation was not updated, violating the docs-update requirement.

Code

src/cache/RedisQueryResultCache.ts[R56-60]

                ...cacheOptions?.options,
            }

-            // Create initial client to test Redis version
-            let tempClient = this.redis.createClient(clientOptions)
-            const isRedis4Plus = typeof tempClient.connect === "function"
-
-            if (isRedis4Plus) {
-                // Redis 4+ detected, recreate with legacyMode for Redis 4.x
-                // (Redis 5 will ignore legacyMode if not needed)
-                clientOptions.legacyMode = true
-                tempClient = this.redis.createClient(clientOptions)
-            }
-
-            // Set as the main client
-            this.client = tempClient
+            this.client = this.redis.createClient(clientOptions)

Evidence

The compliance checklist requires documentation updates for user-facing changes. The PR description
explicitly states legacy redis client versions are being removed and the docs checklist item is left
unchecked, while the code change removes the legacy/compat handling.

Rule 2: Docs updated for user-facing changes
src/cache/RedisQueryResultCache.ts[56-60]

Agent prompt

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

## Issue description
This PR removes support for legacy Redis v3/v4 clients, but documentation was not updated to reflect the new minimum supported Redis client/version and any migration notes.

## Issue Context
The PR itself indicates a user-facing change (dropping Redis v3/v4) and the documentation checklist item is unchecked.

## Fix Focus Areas
- src/cache/RedisQueryResultCache.ts[56-60]

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

Description

New code adds result: any in getFromCache, which weakens type safety and resembles the
prohibited "any-casts to bypass types" style. This violates the requirement to avoid AI-like
type-bypassing patterns.

Code

src/cache/RedisQueryResultCache.ts[R137-139]

+        return this.client.get(key).then((result: any) => {
+            return result ? JSON.parse(result) : undefined
        })

Evidence

The checklist prohibits introducing type-bypassing any usage. The added callback explicitly
annotates result as any in newly changed lines.

Rule 4: Remove AI-generated noise
src/cache/RedisQueryResultCache.ts[137-139]

Agent prompt

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

## Issue description
`getFromCache` introduces `result: any`, which bypasses type checking and violates the "no any-casts to bypass types" requirement.

## Issue Context
`this.client.get(key)` should have a known return type for the chosen redis client types (commonly `string | null`), and JSON parsing should be done with that type.

## Fix Focus Areas
- src/cache/RedisQueryResultCache.ts[137-139]

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

Description

RedisQueryResultCache now has top-level (value) imports of redis and ioredis, which are optional
peer dependencies. Because DataSource imports the cache factory at module load time, apps can crash
on import (and/or TS type resolution) even when cache is not used.

Code

src/cache/RedisQueryResultCache.ts[R7-8]

+import Redis, { Cluster } from "ioredis"
+import { RedisClientType } from "redis"

Evidence

DataSource imports QueryResultCacheFactory, which imports RedisQueryResultCache at top-level,
so the new static imports are evaluated during normal TypeORM module loading. Since redis and
ioredis are optional peer dependencies, they are not guaranteed to be installed, making these
imports a startup-breaking change.

src/cache/RedisQueryResultCache.ts[1-32]
src/cache/QueryResultCacheFactory.ts[1-6]
src/data-source/DataSource.ts[24-35]
package.json[169-199]

Agent prompt

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

### Issue description
`RedisQueryResultCache` now statically imports `redis` and `ioredis`. Since these are optional *peer* dependencies, this can break consumers at runtime/compile-time even if they never enable cache.

### Issue Context
`DataSource` imports `QueryResultCacheFactory` which imports `RedisQueryResultCache` at module scope, so the static imports execute during normal TypeORM initialization.

### Fix Focus Areas
- src/cache/RedisQueryResultCache.ts[1-32]
- src/cache/RedisQueryResultCache.ts[23-32]

### What to change
- Remove value imports from `redis` and `ioredis`.
- Avoid referencing peer-dep types in exported declarations (e.g., keep `protected client: any` or a local structural interface).
- Keep runtime loading via `PlatformTools.load(...)` only, preserving optional peer dependency behavior.

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

Description

The RedisQueryResultCache unit tests are now skipped entirely, removing coverage for cache behavior
during a risky refactor. This increases the likelihood of shipping runtime regressions in
redis/ioredis integrations.

Code

test/unit/cache/redis-query-result-cache.test.ts[8]

+describe.skip("RedisQueryResultCache", () => {

Evidence

The test suite is explicitly disabled via describe.skip, so CI will not exercise any
RedisQueryResultCache behavior or validate the refactor.

test/unit/cache/redis-query-result-cache.test.ts[1-10]

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 RedisQueryResultCache unit suite is fully skipped, and the remaining tests target a removed method (`detectRedisVersion`). This leaves the refactor untested.

### Issue Context
This PR changes command invocation patterns and dependency loading behavior; tests should validate client-specific method signatures and optional dependency behavior.

### Fix Focus Areas
- test/unit/cache/redis-query-result-cache.test.ts[1-107]
- src/cache/RedisQueryResultCache.ts[52-108]
- src/cache/RedisQueryResultCache.ts[156-168]
- src/cache/RedisQueryResultCache.ts[208-210]

### What to change
- Replace `describe.skip(...)` with `describe(...)`.
- Remove/update the `detectRedisVersion` tests.
- Add unit tests that stub the underlying client and assert:
 - For `clientType: "redis"`, `storeInCache` uses the redis-v5-compatible `set` signature.
 - For `clientType: "ioredis"` / `"ioredis/cluster"`, `storeInCache` uses the expected ioredis signature.
 - `deleteKey` calls `del` with the correct argument shape.

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