• Add test suite for index migrations issue #5117
• Create test entities with single and composite indexes
• Verify unique index creation in schema migrations
• Validate idempotent index migration behavior

User entity with composite and single indexes

• Create User entity with PrimaryGeneratedColumn id
• Add name and email columns with indexes
• Define composite unique index IDX_NAME_EMAIL
• Define single column index IDX_NAME

test/functional/indices/indices-migrations/entity/User.ts

SimpleExample entity with multiple index types

• Create SimpleExample entity with PrimaryGeneratedColumn id
• Add userId and choice columns with indexes
• Define composite unique index IDX_USER_ID_CHOICE
• Define single column index IDX_CHOICE
• Add OneToOne relationship to User entity

test/functional/indices/indices-migrations/entity/Example.ts

Index migration test suite with idempotency checks

• Create test suite for index migrations issue #5117
• Test unique index creation in schema migrations
• Verify all three indexes are generated in upQueries
• Test idempotent behavior when indexes already exist

test/functional/indices/indices-migrations/indices-migration.test.ts

Description

The second test asserts there are no schema-diff queries but never ensures the schema has been
built; it implicitly depends on the first test calling SchemaBuilder.build(). This makes the suite
non-hermetic (fails when run in isolation) and increases flakiness/diagnostic cost if the first test
aborts early.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R38-49]

+                await dataSource.driver.createSchemaBuilder().build()
+            }),
+        ))
+    it("should not create unique index if it already exists", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                const sqlInMemory = await dataSource.driver
+                    .createSchemaBuilder()
+                    .log()
+                sqlInMemory.upQueries.length.should.eq(0)
+                sqlInMemory.downQueries.length.should.eq(0)
+            }),

Evidence

The schema is built only in the first test; the second test directly calls log() and expects 0
queries, so it relies on state created by the prior test. Existing schema-builder tests in this repo
typically build within the same test before asserting 0 diffs, keeping tests independent.

test/functional/indices/indices-migrations/indices-migration.test.ts[19-49]
test/github-issues/4897/issue-4897.test.ts[34-44]

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 second test (`should not create unique index if it already exists`) assumes the schema already exists, but it never creates it. This makes the test order-dependent on the previous `it` block.

### Issue Context
If the second test is run alone (e.g., focused run) or the first test fails before calling `build()`, the schema won’t exist and `log()` will legitimately contain queries, failing the test.

### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[38-49]

### Suggested change
In the second test, call `await dataSource.driver.createSchemaBuilder().build()` before calling `.log()` (mirroring existing patterns like `test/github-issues/4897/issue-4897.test.ts`).

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

Description

SimpleExample declares id: string with @PrimaryGeneratedColumn(), but the decorator defaults to
a numeric column type for the increment strategy. This is misleading and can cause incorrect
TypeScript assumptions if the entity is used/extended in future tests.

Code

test/functional/indices/indices-migrations/entity/Example.ts[R14-18]

+    @PrimaryGeneratedColumn()
+    id: string
+
+    @Column({ name: "user_id", nullable: false })
+    userId: number

Evidence

PrimaryGeneratedColumn explicitly sets the column type to Number for the default increment strategy,
so the entity field should be typed as number for accuracy and consistency with existing entities.

test/functional/indices/indices-migrations/entity/Example.ts[11-18]
src/decorator/columns/PrimaryGeneratedColumn.ts[98-107]
test/functional/query-builder/order-by/entity/Comment.ts[8-12]

Agent prompt

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

### Issue description
`SimpleExample.id` is typed as `string` but uses `@PrimaryGeneratedColumn()` with the default `increment` strategy, which uses a numeric column type.

### Issue Context
This is primarily a TypeScript correctness/maintainability issue: runtime values will be numeric while the type says string.

### Fix Focus Areas
- test/functional/indices/indices-migrations/entity/Example.ts[14-16]

### Suggested change
Update to:
- `id: number`

(Alternatively, if the intent is a string id, specify `@PrimaryGeneratedColumn("uuid")`.)

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

Description

In the "detect indices creation" suite, beforeEach(reloadTestingDatabases) calls
DataSource.synchronize(true) which drops the database and rebuilds the schema, including indexes.
As a result, createSchemaBuilder().log() should produce no pending up/down queries, making the
test assertions (upQueries.length > 0, etc.) fail and not test the intended behavior.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R19-29]

+        beforeEach(() => reloadTestingDatabases(dataSources))
+        after(() => closeTestingConnections(dataSources))
+
+        it("should detect indices creation", () =>
+            Promise.all(
+                dataSources.map(async (dataSource) => {
+                    const sqlInMemory = await dataSource.driver
+                        .createSchemaBuilder()
+                        .log()
+                    sqlInMemory.upQueries.length.should.gt(0)
+                    sqlInMemory.downQueries.length.should.gt(0)

Evidence

The test prepares the DB by calling reloadTestingDatabases, which synchronizes the schema.
Synchronization explicitly drops the database (when true) and runs schema builder build(), which
brings the schema fully up-to-date. Therefore, immediately afterwards, schema diff logging should
yield zero queries, contradicting the test’s expectation of index-creation queries.

test/functional/indices/indices-migrations/indices-migration.test.ts[11-40]
test/utils/test-utils.ts[504-509]
src/data-source/DataSource.ts[303-311]
src/data-source/DataSource.ts[261-272]

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 suite intended to verify that schema diff logging detects index creation is currently synchronizing the schema in `beforeEach`, which drops and rebuilds tables/indexes. This makes `.log()` report no pending queries and breaks the test’s assertions.

### Issue Context
`reloadTestingDatabases()` calls `connection.synchronize(true)`, which drops the database and runs `schemaBuilder.build()`.

### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[11-41]
- test/utils/test-utils.ts[504-509]
- src/data-source/DataSource.ts[303-311]

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

Description

The second test asserts there are no schema-diff queries but never ensures the schema has been
built; it implicitly depends on the first test calling SchemaBuilder.build(). This makes the suite
non-hermetic (fails when run in isolation) and increases flakiness/diagnostic cost if the first test
aborts early.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R38-49]

+                await dataSource.driver.createSchemaBuilder().build()
+            }),
+        ))
+    it("should not create unique index if it already exists", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                const sqlInMemory = await dataSource.driver
+                    .createSchemaBuilder()
+                    .log()
+                sqlInMemory.upQueries.length.should.eq(0)
+                sqlInMemory.downQueries.length.should.eq(0)
+            }),

Evidence

The schema is built only in the first test; the second test directly calls log() and expects 0
queries, so it relies on state created by the prior test. Existing schema-builder tests in this repo
typically build within the same test before asserting 0 diffs, keeping tests independent.

test/functional/indices/indices-migrations/indices-migration.test.ts[19-49]
test/github-issues/4897/issue-4897.test.ts[34-44]

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 second test (`should not create unique index if it already exists`) assumes the schema already exists, but it never creates it. This makes the test order-dependent on the previous `it` block.
### Issue Context
If the second test is run alone (e.g., focused run) or the first test fails before calling `build()`, the schema won’t exist and `log()` will legitimately contain queries, failing the test.
### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[38-49]
### Suggested change
In the second test, call `await dataSource.driver.createSchemaBuilder().build()` before calling `.log()` (mirroring existing patterns like `test/github-issues/4897/issue-4897.test.ts`).

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

Description

SimpleExample declares id: string with @PrimaryGeneratedColumn(), but the decorator defaults to
a numeric column type for the increment strategy. This is misleading and can cause incorrect
TypeScript assumptions if the entity is used/extended in future tests.

Code

test/functional/indices/indices-migrations/entity/Example.ts[R14-18]

+    @PrimaryGeneratedColumn()
+    id: string
+
+    @Column({ name: "user_id", nullable: false })
+    userId: number

Evidence

PrimaryGeneratedColumn explicitly sets the column type to Number for the default increment strategy,
so the entity field should be typed as number for accuracy and consistency with existing entities.

test/functional/indices/indices-migrations/entity/Example.ts[11-18]
src/decorator/columns/PrimaryGeneratedColumn.ts[98-107]
test/functional/query-builder/order-by/entity/Comment.ts[8-12]

Agent prompt

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

## Issue description
`SimpleExample.id` is typed as `string` but uses `@PrimaryGeneratedColumn()` with the default `increment` strategy, which uses a numeric column type.
### Issue Context
This is primarily a TypeScript correctness/maintainability issue: runtime values will be numeric while the type says string.
### Fix Focus Areas
- test/functional/indices/indices-migrations/entity/Example.ts[14-16]
### Suggested change
Update to:
- `id: number`
(Alternatively, if the intent is a string id, specify `@PrimaryGeneratedColumn("uuid")`.)

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

Description

reloadTestingDatabases is imported in the new test but never used. Because the repo’s TypeScript
config enables noUnusedLocals, this will cause compilation to fail and prevent the test suite from
running.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R2-6]

+import {
+    closeTestingConnections,
+    createTestingConnections,
+    reloadTestingDatabases,
+} from "../../../utils/test-utils"

Evidence

The test file imports reloadTestingDatabases but contains no references to it, and the
repository’s tsconfig enforces unused-local errors at compile time (noUnusedLocals: true).

test/functional/indices/indices-migrations/indices-migration.test.ts[1-6]
tsconfig.json[1-23]

Agent prompt

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

### Issue description
The new test file imports `reloadTestingDatabases` but never uses it. With `noUnusedLocals: true`, TypeScript compilation fails.

### Issue Context
This repository enables `noUnusedLocals` in `tsconfig.json`, so unused imports are build-breaking.

### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[1-6]
- tsconfig.json[1-23]

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

Description

The second test asserts there are no schema-diff queries but never ensures the schema has been
built; it implicitly depends on the first test calling SchemaBuilder.build(). This makes the suite
non-hermetic (fails when run in isolation) and increases flakiness/diagnostic cost if the first test
aborts early.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R38-49]

+                await dataSource.driver.createSchemaBuilder().build()
+            }),
+        ))
+    it("should not create unique index if it already exists", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                const sqlInMemory = await dataSource.driver
+                    .createSchemaBuilder()
+                    .log()
+                sqlInMemory.upQueries.length.should.eq(0)
+                sqlInMemory.downQueries.length.should.eq(0)
+            }),

Evidence

The schema is built only in the first test; the second test directly calls log() and expects 0
queries, so it relies on state created by the prior test. Existing schema-builder tests in this repo
typically build within the same test before asserting 0 diffs, keeping tests independent.

test/functional/indices/indices-migrations/indices-migration.test.ts[19-49]
test/github-issues/4897/issue-4897.test.ts[34-44]

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 second test (`should not create unique index if it already exists`) assumes the schema already exists, but it never creates it. This makes the test order-dependent on the previous `it` block.
### Issue Context
If the second test is run alone (e.g., focused run) or the first test fails before calling `build()`, the schema won’t exist and `log()` will legitimately contain queries, failing the test.
### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[38-49]
### Suggested change
In the second test, call `await dataSource.driver.createSchemaBuilder().build()` before calling `.log()` (mirroring existing patterns like `test/github-issues/4897/issue-4897.test.ts`).

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

Description

In the "detect indices creation" suite, beforeEach(reloadTestingDatabases) calls
DataSource.synchronize(true) which drops the database and rebuilds the schema, including indexes.
As a result, createSchemaBuilder().log() should produce no pending up/down queries, making the
test assertions (upQueries.length > 0, etc.) fail and not test the intended behavior.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R19-29]

+        beforeEach(() => reloadTestingDatabases(dataSources))
+        after(() => closeTestingConnections(dataSources))
+
+        it("should detect indices creation", () =>
+            Promise.all(
+                dataSources.map(async (dataSource) => {
+                    const sqlInMemory = await dataSource.driver
+                        .createSchemaBuilder()
+                        .log()
+                    sqlInMemory.upQueries.length.should.gt(0)
+                    sqlInMemory.downQueries.length.should.gt(0)

Evidence

The test prepares the DB by calling reloadTestingDatabases, which synchronizes the schema.
Synchronization explicitly drops the database (when true) and runs schema builder build(), which
brings the schema fully up-to-date. Therefore, immediately afterwards, schema diff logging should
yield zero queries, contradicting the test’s expectation of index-creation queries.

test/functional/indices/indices-migrations/indices-migration.test.ts[11-40]
test/utils/test-utils.ts[504-509]
src/data-source/DataSource.ts[303-311]
src/data-source/DataSource.ts[261-272]

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 suite intended to verify that schema diff logging detects index creation is currently synchronizing the schema in `beforeEach`, which drops and rebuilds tables/indexes. This makes `.log()` report no pending queries and breaks the test’s assertions.
### Issue Context
`reloadTestingDatabases()` calls `connection.synchronize(true)`, which drops the database and runs `schemaBuilder.build()`.
### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[11-41]
- test/utils/test-utils.ts[504-509]
- src/data-source/DataSource.ts[303-311]

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

Description

SimpleExample declares id: string with @PrimaryGeneratedColumn(), but the decorator defaults to
a numeric column type for the increment strategy. This is misleading and can cause incorrect
TypeScript assumptions if the entity is used/extended in future tests.

Code

test/functional/indices/indices-migrations/entity/Example.ts[R14-18]

+    @PrimaryGeneratedColumn()
+    id: string
+
+    @Column({ name: "user_id", nullable: false })
+    userId: number

Evidence

PrimaryGeneratedColumn explicitly sets the column type to Number for the default increment strategy,
so the entity field should be typed as number for accuracy and consistency with existing entities.

test/functional/indices/indices-migrations/entity/Example.ts[11-18]
src/decorator/columns/PrimaryGeneratedColumn.ts[98-107]
test/functional/query-builder/order-by/entity/Comment.ts[8-12]

Agent prompt

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

## Issue description
`SimpleExample.id` is typed as `string` but uses `@PrimaryGeneratedColumn()` with the default `increment` strategy, which uses a numeric column type.
### Issue Context
This is primarily a TypeScript correctness/maintainability issue: runtime values will be numeric while the type says string.
### Fix Focus Areas
- test/functional/indices/indices-migrations/entity/Example.ts[14-16]
### Suggested change
Update to:
- `id: number`
(Alternatively, if the intent is a string id, specify `@PrimaryGeneratedColumn("uuid")`.)

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

Description

SimpleExample declares id: string with @PrimaryGeneratedColumn(), but the decorator defaults to
a numeric column type for the increment strategy. This is misleading and can cause incorrect
TypeScript assumptions if the entity is used/extended in future tests.

Code

test/functional/indices/indices-migrations/entity/Example.ts[R14-18]

+    @PrimaryGeneratedColumn()
+    id: string
+
+    @Column({ name: "user_id", nullable: false })
+    userId: number

Evidence

PrimaryGeneratedColumn explicitly sets the column type to Number for the default increment strategy,
so the entity field should be typed as number for accuracy and consistency with existing entities.

test/functional/indices/indices-migrations/entity/Example.ts[11-18]
src/decorator/columns/PrimaryGeneratedColumn.ts[98-107]
test/functional/query-builder/order-by/entity/Comment.ts[8-12]

Agent prompt

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

## Issue description
`SimpleExample.id` is typed as `string` but uses `@PrimaryGeneratedColumn()` with the default `increment` strategy, which uses a numeric column type.
### Issue Context
This is primarily a TypeScript correctness/maintainability issue: runtime values will be numeric while the type says string.
### Fix Focus Areas
- test/functional/indices/indices-migrations/entity/Example.ts[14-16]
### Suggested change
Update to:
- `id: number`
(Alternatively, if the intent is a string id, specify `@PrimaryGeneratedColumn("uuid")`.)

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

Description

The second test asserts there are no schema-diff queries but never ensures the schema has been
built; it implicitly depends on the first test calling SchemaBuilder.build(). This makes the suite
non-hermetic (fails when run in isolation) and increases flakiness/diagnostic cost if the first test
aborts early.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R38-49]

+                await dataSource.driver.createSchemaBuilder().build()
+            }),
+        ))
+    it("should not create unique index if it already exists", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                const sqlInMemory = await dataSource.driver
+                    .createSchemaBuilder()
+                    .log()
+                sqlInMemory.upQueries.length.should.eq(0)
+                sqlInMemory.downQueries.length.should.eq(0)
+            }),

Evidence

The schema is built only in the first test; the second test directly calls log() and expects 0
queries, so it relies on state created by the prior test. Existing schema-builder tests in this repo
typically build within the same test before asserting 0 diffs, keeping tests independent.

test/functional/indices/indices-migrations/indices-migration.test.ts[19-49]
test/github-issues/4897/issue-4897.test.ts[34-44]

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 second test (`should not create unique index if it already exists`) assumes the schema already exists, but it never creates it. This makes the test order-dependent on the previous `it` block.
### Issue Context
If the second test is run alone (e.g., focused run) or the first test fails before calling `build()`, the schema won’t exist and `log()` will legitimately contain queries, failing the test.
### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[38-49]
### Suggested change
In the second test, call `await dataSource.driver.createSchemaBuilder().build()` before calling `.log()` (mirroring existing patterns like `test/github-issues/4897/issue-4897.test.ts`).

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

Description

In the "detect indices creation" suite, beforeEach(reloadTestingDatabases) calls
DataSource.synchronize(true) which drops the database and rebuilds the schema, including indexes.
As a result, createSchemaBuilder().log() should produce no pending up/down queries, making the
test assertions (upQueries.length > 0, etc.) fail and not test the intended behavior.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R19-29]

+        beforeEach(() => reloadTestingDatabases(dataSources))
+        after(() => closeTestingConnections(dataSources))
+
+        it("should detect indices creation", () =>
+            Promise.all(
+                dataSources.map(async (dataSource) => {
+                    const sqlInMemory = await dataSource.driver
+                        .createSchemaBuilder()
+                        .log()
+                    sqlInMemory.upQueries.length.should.gt(0)
+                    sqlInMemory.downQueries.length.should.gt(0)

Evidence

The test prepares the DB by calling reloadTestingDatabases, which synchronizes the schema.
Synchronization explicitly drops the database (when true) and runs schema builder build(), which
brings the schema fully up-to-date. Therefore, immediately afterwards, schema diff logging should
yield zero queries, contradicting the test’s expectation of index-creation queries.

test/functional/indices/indices-migrations/indices-migration.test.ts[11-40]
test/utils/test-utils.ts[504-509]
src/data-source/DataSource.ts[303-311]
src/data-source/DataSource.ts[261-272]

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 suite intended to verify that schema diff logging detects index creation is currently synchronizing the schema in `beforeEach`, which drops and rebuilds tables/indexes. This makes `.log()` report no pending queries and breaks the test’s assertions.
### Issue Context
`reloadTestingDatabases()` calls `connection.synchronize(true)`, which drops the database and runs `schemaBuilder.build()`.
### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[11-41]
- test/utils/test-utils.ts[504-509]
- src/data-source/DataSource.ts[303-311]

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

Description

The second test asserts there are no schema-diff queries but never ensures the schema has been
built; it implicitly depends on the first test calling SchemaBuilder.build(). This makes the suite
non-hermetic (fails when run in isolation) and increases flakiness/diagnostic cost if the first test
aborts early.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R38-49]

+                await dataSource.driver.createSchemaBuilder().build()
+            }),
+        ))
+    it("should not create unique index if it already exists", () =>
+        Promise.all(
+            dataSources.map(async (dataSource) => {
+                const sqlInMemory = await dataSource.driver
+                    .createSchemaBuilder()
+                    .log()
+                sqlInMemory.upQueries.length.should.eq(0)
+                sqlInMemory.downQueries.length.should.eq(0)
+            }),

Evidence

The schema is built only in the first test; the second test directly calls log() and expects 0
queries, so it relies on state created by the prior test. Existing schema-builder tests in this repo
typically build within the same test before asserting 0 diffs, keeping tests independent.

test/functional/indices/indices-migrations/indices-migration.test.ts[19-49]
test/github-issues/4897/issue-4897.test.ts[34-44]

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 second test (`should not create unique index if it already exists`) assumes the schema already exists, but it never creates it. This makes the test order-dependent on the previous `it` block.
### Issue Context
If the second test is run alone (e.g., focused run) or the first test fails before calling `build()`, the schema won’t exist and `log()` will legitimately contain queries, failing the test.
### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[38-49]
### Suggested change
In the second test, call `await dataSource.driver.createSchemaBuilder().build()` before calling `.log()` (mirroring existing patterns like `test/github-issues/4897/issue-4897.test.ts`).

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

Description

The new indices-migrations tests assume SchemaBuilder.log() produces SQL upQueries containing index
names, but MongoDB's schema builder returns an empty SqlInMemory; if MongoDB is enabled in
ormconfig, these tests will fail deterministically.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R10-16]

+        before(
+            async () =>
+                (dataSources = await createTestingConnections({
+                    entities: [__dirname + "/entity/*{.js,.ts}"],
+                    schemaCreate: false,
+                    dropSchema: true,
+                })),

Evidence

The test suite creates testing connections without specifying enabledDrivers, so it runs against all
configured drivers that aren't implicitly disabled. For MongoDB, SchemaBuilder.log() always returns
an empty SqlInMemory, so the test’s assertions that expect SQL queries and index-name substrings
will fail when MongoDB is included.

test/functional/indices/indices-migrations/indices-migration.test.ts[10-16]
test/functional/indices/indices-migrations/indices-migration.test.ts[20-37]
test/utils/test-utils.ts[226-254]
src/schema-builder/MongoSchemaBuilder.ts[78-83]
ormconfig.sample.json[94-103]

Agent prompt

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

### Issue description
The new indices-migrations tests assume SQL-based schema builder output. If MongoDB is enabled in the test configuration, `MongoSchemaBuilder.log()` returns an empty `SqlInMemory`, causing these tests to fail.

### Issue Context
`createTestingConnections()` will include all configured drivers unless `enabledDrivers` is provided. MongoDB is often disabled implicitly, but can be enabled explicitly in some environments.

### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[10-16]
- test/functional/indices/indices-migrations/indices-migration.test.ts[44-51]

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

Description

The test asserts downQueries.length > 0 in the index-creation scenario, but downQueries are not
essential for validating index detection and can be empty for some schema builders (e.g., MongoDB),
making the test more fragile than needed.

Code

test/functional/indices/indices-migrations/indices-migration.test.ts[R23-28]

+                    const sqlInMemory = await dataSource.driver
+                        .createSchemaBuilder()
+                        .log()
+                    sqlInMemory.upQueries.length.should.gt(0)
+                    sqlInMemory.downQueries.length.should.gt(0)
+

Evidence

The test requires downQueries to be non-empty, but MongoDB’s schema builder returns a fresh empty
SqlInMemory (no upQueries/downQueries). Even if MongoDB is usually excluded, this assertion is not
directly tied to #5117’s goal (detect index creation) and increases the chance of
environment/driver-specific failures.

test/functional/indices/indices-migrations/indices-migration.test.ts[23-28]
src/schema-builder/MongoSchemaBuilder.ts[81-83]

Agent prompt

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

### Issue description
`downQueries.length.should.gt(0)` is not required to validate index creation detection and can cause unnecessary failures when a schema builder does not populate downQueries.

### Issue Context
The test already validates that upQueries exist and contain the expected index names.

### Fix Focus Areas
- test/functional/indices/indices-migrations/indices-migration.test.ts[23-28]

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

Description

SimpleExample declares id: string with @PrimaryGeneratedColumn(), but the decorator defaults to
a numeric column type for the increment strategy. This is misleading and can cause incorrect
TypeScript assumptions if the entity is used/extended in future tests.

Code

test/functional/indices/indices-migrations/entity/Example.ts[R14-18]

+    @PrimaryGeneratedColumn()
+    id: string
+
+    @Column({ name: "user_id", nullable: false })
+    userId: number

Evidence

PrimaryGeneratedColumn explicitly sets the column type to Number for the default increment strategy,
so the entity field should be typed as number for accuracy and consistency with existing entities.

test/functional/indices/indices-migrations/entity/Example.ts[11-18]
src/decorator/columns/PrimaryGeneratedColumn.ts[98-107]
test/functional/query-builder/order-by/entity/Comment.ts[8-12]

Agent prompt

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

## Issue description
`SimpleExample.id` is typed as `string` but uses `@PrimaryGeneratedColumn()` with the default `increment` strategy, which uses a numeric column type.
### Issue Context
This is primarily a TypeScript correctness/maintainability issue: runtime values will be numeric while the type says string.
### Fix Focus Areas
- test/functional/indices/indices-migrations/entity/Example.ts[14-16]
### Suggested change
Update to:
- `id: number`
(Alternatively, if the intent is a string id, specify `@PrimaryGeneratedColumn("uuid")`.)

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