docs(transactions): clarify CockroachDB isolation level behavior and add tests - #12350

Description

The CockroachDB isolation tests hardcode the expected effective isolation level for “default
settings” but do not set/read the cluster settings that control CockroachDB’s fallback behavior,
making the assertions environment-dependent and prone to failure (e.g., REPEATABLE READ can run as
SERIALIZABLE when the repeatable-read setting is disabled). This can break CI or local runs
depending on the cluster’s configuration.

Code

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[R29-37]

+const getExpectedIsolationForDefaultSettings = (
+    requestedIsolationLevel: string,
+) => {
+    if (requestedIsolationLevel === "READ UNCOMMITTED") {
+        return "READ COMMITTED"
+    }
+
+    return requestedIsolationLevel
+}

Evidence

getExpectedIsolationForDefaultSettings only remaps READ UNCOMMITTED→READ COMMITTED and otherwise
assumes the requested level is the effective level; this is then used to assert the server’s
effective isolation in both the “supported” and “defined in data source” suites. However, the PR’s
own CockroachDB docs (and the test file’s own fallbackCases) state that the effective isolation
can change based on sql.txn.read_committed_isolation.enabled and
sql.txn.repeatable_read_isolation.enabled, which these suites do not control before asserting.

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[29-37]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[66-83]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[164-175]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[202-270]
docs/docs/transactions.mdx[63-76]

Agent prompt

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

## Issue description
`cockroachdb-isolation.test.ts` asserts the effective isolation level returned by `SHOW TRANSACTION ISOLATION LEVEL`, but the expected values depend on CockroachDB cluster settings. The tests currently don’t set/read those settings for the “supported” and “defined in data source” suites, so results can vary by environment.
### Issue Context
CockroachDB may map requested weaker levels to stronger ones depending on:
- `sql.txn.read_committed_isolation.enabled`
- `sql.txn.repeatable_read_isolation.enabled`
The test file already encodes this dependency in `fallbackCases`, but other suites still assume a fixed default mapping.
### Fix Focus Areas
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[29-37]
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[66-83]
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[164-175]
### Suggested fix
Choose one deterministic approach:
1) **Set known cluster settings** in `before()` hooks for the “supported” and “defined in data source” suites (e.g., enable `readCommitted` and `repeatableRead`) and update expected mapping accordingly.
OR
2) **Compute expected effective isolation dynamically** by querying current cluster settings (e.g., `SHOW CLUSTER SETTING ...`) and using the same mapping rules as `fallbackCases` for assertions.
Either way, avoid assuming “default settings” without enforcing or reading them.

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

Description

The CockroachDB isolation fallback tests change cluster-wide settings via SET CLUSTER SETTING ...
and never reset them, leaving sql.txn.repeatable_read_isolation.enabled disabled after the suite
completes. This can change behavior of later CockroachDB tests against the same cluster and make the
test run order-dependent/flaky.

Code

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[R257-287]

+                name: "REPEATABLE READ -> SERIALIZABLE when repeatable read setting is disabled",
+                requestedIsolationLevel: "REPEATABLE READ",
+                settings: {
+                    readCommitted: true,
+                    repeatableRead: false,
+                },
+                expectedIsolationLevel: "SERIALIZABLE",
+            },
+        ]
+
+        for (const testCase of fallbackCases) {
+            it(testCase.name, () =>
+                Promise.all(
+                    dataSources.map(async (dataSource) => {
+                        await setIsolationClusterSettings(
+                            dataSource,
+                            testCase.settings,
+                        )
+
+                        await dataSource.manager.transaction(
+                            testCase.requestedIsolationLevel,
+                            async (entityManager) => {
+                                await getCurrentTransactionLevelAndAssert(
+                                    entityManager,
+                                    testCase.expectedIsolationLevel,
+                                )
+                            },
+                        )
+                    }),
+                ),
+            )

Evidence

The fallback suite’s last case sets repeatableRead: false, and each case applies the settings with
SET CLUSTER SETTING; there is no after/afterEach hook to restore the previous values.
Separately, the shared test harness enables sql.txn.repeatable_read_isolation.enabled = 'true'
during CockroachDB connection setup, implying other tests may assume it remains enabled unless
explicitly changed and reset.

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[39-52]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[183-290]
test/utils/test-utils.ts[406-437]

Agent prompt

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

## Issue description
`test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts` modifies CockroachDB *cluster-wide* settings in the "fallback behavior" suite but never restores them. Because these settings are global, they can leak into subsequent CockroachDB tests and make the suite order-dependent/flaky.
### Issue Context
The last fallback case sets `sql.txn.repeatable_read_isolation.enabled` to `false`, and the suite ends without resetting it. The test harness (`test/utils/test-utils.ts`) enables `sql.txn.repeatable_read_isolation.enabled = 'true'` during CockroachDB setup, suggesting other tests may rely on that baseline.
### Fix Focus Areas
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[183-290]
### Suggested fix
- Capture the original values at the start of the "fallback behavior" describe block (e.g., `SHOW CLUSTER SETTING sql.txn.read_committed_isolation.enabled` and `SHOW CLUSTER SETTING sql.txn.repeatable_read_isolation.enabled`).
- Add an `afterEach` (or at minimum `after`) hook that restores both settings back to their original values (or to the known baseline used by the test harness, e.g. `readCommitted=true`, `repeatableRead=true`).
- Ensure restoration happens even if a test fails (prefer `afterEach`).

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

Description

The CockroachDB section says REPEATABLE READ is available behind
sql.txn.repeatable_read_isolation.enabled, but it also states CockroachDB “does not implement
weaker isolation levels at all” and ignores weaker requests. This contradiction makes the
documentation incorrect/confusing about when REPEATABLE READ is actually honored.

Code

docs/docs/transactions.mdx[R64-67]

+- `REPEATABLE READ` - requires the cluster setting `sql.txn.repeatable_read_isolation.enabled`, which is disabled by default (introduced in v24.3.0)
- `SERIALIZABLE` (default)
CockroachDB does not implement weaker isolation levels at all. When you request `READ UNCOMMITTED` or `REPEATABLE READ` via SQL (e.g. `BEGIN TRANSACTION ISOLATION LEVEL READ UNCOMMITTED`), CockroachDB accepts the syntax, silently ignores the requested weakness, and runs the transaction at a stricter level instead — no warning, no error:

Evidence

The doc first introduces REPEATABLE READ as a configurable isolation level (behind a cluster
setting), then immediately claims CockroachDB does not implement weaker isolation levels at all,
which conflicts with the earlier statement. Repo test setup also explicitly enables the REPEATABLE
READ cluster setting, reinforcing that this repo expects an enabled mode to exist.

docs/docs/transactions.mdx[63-70]
test/utils/test-utils.ts[390-421]

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 CockroachDB docs are internally inconsistent: they say `REPEATABLE READ` exists behind `sql.txn.repeatable_read_isolation.enabled`, but also claim CockroachDB does not implement weaker isolation levels at all and ignores weaker requests.
### Issue Context
This section is meant to explain how CockroachDB interprets requested isolation levels; it needs to distinguish behavior when the feature flag is enabled vs disabled.
### Fix Focus Areas
- docs/docs/transactions.mdx[63-71]
### Suggested change
Adjust the blanket statement to be conditional (e.g., describe historical behavior / behavior when the relevant cluster settings are disabled), so it does not contradict the preceding bullet list.

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

Description

The new REPEATABLE READ bullet uses a hyphen (-) instead of the em dash (—) used by the
surrounding items, introducing inconsistent style in the same list. This violates the requirement to
avoid style inconsistent with the file.

Code

docs/docs/transactions.mdx[64]

+- `REPEATABLE READ` - requires the cluster setting `sql.txn.repeatable_read_isolation.enabled`, which is disabled by default (introduced in v24.3.0)

Evidence

PR Compliance ID 4 forbids introducing style inconsistent with the file; the added REPEATABLE READ
list item uses - while adjacent items use — in the same CockroachDB isolation level list.

Rule 4: Remove AI-generated noise
docs/docs/transactions.mdx[64-64]

Agent prompt

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

## Issue description
In `docs/docs/transactions.mdx`, the added CockroachDB isolation level bullet for `REPEATABLE READ` uses `-` as the separator, while the neighboring bullets use an em dash (`—`). This creates an inconsistent style within the same list.
## Issue Context
The compliance checklist requires avoiding style inconsistent with the file.
## Fix Focus Areas
- docs/docs/transactions.mdx[64-64]

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

Description

The fallback suite’s async after-hook performs cluster-setting updates before closing connections,
so if any SET CLUSTER SETTING query fails the connections won’t be closed. This can leave open
handles and make the test run hang or cascade failures.

Code

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[R194-204]

+        after(async () => {
+            await Promise.all(
+                dataSources.map((dataSource) =>
+                    setIsolationClusterSettings(dataSource, {
+                        readCommitted: true,
+                        repeatableRead: true,
+                    }),
+                ),
+            )
+            await closeTestingConnections(dataSources)
+        })

Evidence

The after-hook awaits Promise.all of setIsolationClusterSettings, then closes connections; a
rejection from the first step prevents closeTestingConnections from running. This is a new risk
introduced by adding extra async cleanup logic to the after-hook.

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[39-52]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[194-204]

Agent prompt

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

## Issue description
If resetting CockroachDB cluster settings fails in the fallback suite’s `after()` hook, `closeTestingConnections()` is skipped.
### Issue Context
The after-hook performs multiple awaited operations; cleanup should be resilient so connections are always closed.
### Fix Focus Areas
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[194-204]
### Proposed fix
Wrap the reset block in a `try { ... } finally { await closeTestingConnections(dataSources) }` so connections are closed even if `setIsolationClusterSettings` throws/rejects.

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

Description

The CockroachDB isolation tests hardcode the expected effective isolation level for “default
settings” but do not set/read the cluster settings that control CockroachDB’s fallback behavior,
making the assertions environment-dependent and prone to failure (e.g., REPEATABLE READ can run as
SERIALIZABLE when the repeatable-read setting is disabled). This can break CI or local runs
depending on the cluster’s configuration.

Code

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[R29-37]

+const getExpectedIsolationForDefaultSettings = (
+    requestedIsolationLevel: string,
+) => {
+    if (requestedIsolationLevel === "READ UNCOMMITTED") {
+        return "READ COMMITTED"
+    }
+
+    return requestedIsolationLevel
+}

Evidence

getExpectedIsolationForDefaultSettings only remaps READ UNCOMMITTED→READ COMMITTED and otherwise
assumes the requested level is the effective level; this is then used to assert the server’s
effective isolation in both the “supported” and “defined in data source” suites. However, the PR’s
own CockroachDB docs (and the test file’s own fallbackCases) state that the effective isolation
can change based on sql.txn.read_committed_isolation.enabled and
sql.txn.repeatable_read_isolation.enabled, which these suites do not control before asserting.

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[29-37]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[66-83]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[164-175]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[202-270]
docs/docs/transactions.mdx[63-76]

Agent prompt

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

## Issue description
`cockroachdb-isolation.test.ts` asserts the effective isolation level returned by `SHOW TRANSACTION ISOLATION LEVEL`, but the expected values depend on CockroachDB cluster settings. The tests currently don’t set/read those settings for the “supported” and “defined in data source” suites, so results can vary by environment.
### Issue Context
CockroachDB may map requested weaker levels to stronger ones depending on:
- `sql.txn.read_committed_isolation.enabled`
- `sql.txn.repeatable_read_isolation.enabled`
The test file already encodes this dependency in `fallbackCases`, but other suites still assume a fixed default mapping.
### Fix Focus Areas
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[29-37]
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[66-83]
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[164-175]
### Suggested fix
Choose one deterministic approach:
1) **Set known cluster settings** in `before()` hooks for the “supported” and “defined in data source” suites (e.g., enable `readCommitted` and `repeatableRead`) and update expected mapping accordingly.
OR
2) **Compute expected effective isolation dynamically** by querying current cluster settings (e.g., `SHOW CLUSTER SETTING ...`) and using the same mapping rules as `fallbackCases` for assertions.
Either way, avoid assuming “default settings” without enforcing or reading them.

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

Description

The CockroachDB isolation fallback tests change cluster-wide settings via SET CLUSTER SETTING ...
and never reset them, leaving sql.txn.repeatable_read_isolation.enabled disabled after the suite
completes. This can change behavior of later CockroachDB tests against the same cluster and make the
test run order-dependent/flaky.

Code

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[R257-287]

+                name: "REPEATABLE READ -> SERIALIZABLE when repeatable read setting is disabled",
+                requestedIsolationLevel: "REPEATABLE READ",
+                settings: {
+                    readCommitted: true,
+                    repeatableRead: false,
+                },
+                expectedIsolationLevel: "SERIALIZABLE",
+            },
+        ]
+
+        for (const testCase of fallbackCases) {
+            it(testCase.name, () =>
+                Promise.all(
+                    dataSources.map(async (dataSource) => {
+                        await setIsolationClusterSettings(
+                            dataSource,
+                            testCase.settings,
+                        )
+
+                        await dataSource.manager.transaction(
+                            testCase.requestedIsolationLevel,
+                            async (entityManager) => {
+                                await getCurrentTransactionLevelAndAssert(
+                                    entityManager,
+                                    testCase.expectedIsolationLevel,
+                                )
+                            },
+                        )
+                    }),
+                ),
+            )

Evidence

The fallback suite’s last case sets repeatableRead: false, and each case applies the settings with
SET CLUSTER SETTING; there is no after/afterEach hook to restore the previous values.
Separately, the shared test harness enables sql.txn.repeatable_read_isolation.enabled = 'true'
during CockroachDB connection setup, implying other tests may assume it remains enabled unless
explicitly changed and reset.

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[39-52]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[183-290]
test/utils/test-utils.ts[406-437]

Agent prompt

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

## Issue description
`test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts` modifies CockroachDB *cluster-wide* settings in the "fallback behavior" suite but never restores them. Because these settings are global, they can leak into subsequent CockroachDB tests and make the suite order-dependent/flaky.
### Issue Context
The last fallback case sets `sql.txn.repeatable_read_isolation.enabled` to `false`, and the suite ends without resetting it. The test harness (`test/utils/test-utils.ts`) enables `sql.txn.repeatable_read_isolation.enabled = 'true'` during CockroachDB setup, suggesting other tests may rely on that baseline.
### Fix Focus Areas
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[183-290]
### Suggested fix
- Capture the original values at the start of the "fallback behavior" describe block (e.g., `SHOW CLUSTER SETTING sql.txn.read_committed_isolation.enabled` and `SHOW CLUSTER SETTING sql.txn.repeatable_read_isolation.enabled`).
- Add an `afterEach` (or at minimum `after`) hook that restores both settings back to their original values (or to the known baseline used by the test harness, e.g. `readCommitted=true`, `repeatableRead=true`).
- Ensure restoration happens even if a test fails (prefer `afterEach`).

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

Description

The CockroachDB section says REPEATABLE READ is available behind
sql.txn.repeatable_read_isolation.enabled, but it also states CockroachDB “does not implement
weaker isolation levels at all” and ignores weaker requests. This contradiction makes the
documentation incorrect/confusing about when REPEATABLE READ is actually honored.

Code

docs/docs/transactions.mdx[R64-67]

+- `REPEATABLE READ` - requires the cluster setting `sql.txn.repeatable_read_isolation.enabled`, which is disabled by default (introduced in v24.3.0)
- `SERIALIZABLE` (default)
CockroachDB does not implement weaker isolation levels at all. When you request `READ UNCOMMITTED` or `REPEATABLE READ` via SQL (e.g. `BEGIN TRANSACTION ISOLATION LEVEL READ UNCOMMITTED`), CockroachDB accepts the syntax, silently ignores the requested weakness, and runs the transaction at a stricter level instead — no warning, no error:

Evidence

The doc first introduces REPEATABLE READ as a configurable isolation level (behind a cluster
setting), then immediately claims CockroachDB does not implement weaker isolation levels at all,
which conflicts with the earlier statement. Repo test setup also explicitly enables the REPEATABLE
READ cluster setting, reinforcing that this repo expects an enabled mode to exist.

docs/docs/transactions.mdx[63-70]
test/utils/test-utils.ts[390-421]

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 CockroachDB docs are internally inconsistent: they say `REPEATABLE READ` exists behind `sql.txn.repeatable_read_isolation.enabled`, but also claim CockroachDB does not implement weaker isolation levels at all and ignores weaker requests.
### Issue Context
This section is meant to explain how CockroachDB interprets requested isolation levels; it needs to distinguish behavior when the feature flag is enabled vs disabled.
### Fix Focus Areas
- docs/docs/transactions.mdx[63-71]
### Suggested change
Adjust the blanket statement to be conditional (e.g., describe historical behavior / behavior when the relevant cluster settings are disabled), so it does not contradict the preceding bullet list.

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

Description

The new REPEATABLE READ bullet uses a hyphen (-) instead of the em dash (—) used by the
surrounding items, introducing inconsistent style in the same list. This violates the requirement to
avoid style inconsistent with the file.

Code

docs/docs/transactions.mdx[64]

+- `REPEATABLE READ` - requires the cluster setting `sql.txn.repeatable_read_isolation.enabled`, which is disabled by default (introduced in v24.3.0)

Evidence

PR Compliance ID 4 forbids introducing style inconsistent with the file; the added REPEATABLE READ
list item uses - while adjacent items use — in the same CockroachDB isolation level list.

Rule 4: Remove AI-generated noise
docs/docs/transactions.mdx[64-64]

Agent prompt

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

## Issue description
In `docs/docs/transactions.mdx`, the added CockroachDB isolation level bullet for `REPEATABLE READ` uses `-` as the separator, while the neighboring bullets use an em dash (`—`). This creates an inconsistent style within the same list.
## Issue Context
The compliance checklist requires avoiding style inconsistent with the file.
## Fix Focus Areas
- docs/docs/transactions.mdx[64-64]

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

Description

The fallback suite’s async after-hook performs cluster-setting updates before closing connections,
so if any SET CLUSTER SETTING query fails the connections won’t be closed. This can leave open
handles and make the test run hang or cascade failures.

Code

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[R194-204]

+        after(async () => {
+            await Promise.all(
+                dataSources.map((dataSource) =>
+                    setIsolationClusterSettings(dataSource, {
+                        readCommitted: true,
+                        repeatableRead: true,
+                    }),
+                ),
+            )
+            await closeTestingConnections(dataSources)
+        })

Evidence

The after-hook awaits Promise.all of setIsolationClusterSettings, then closes connections; a
rejection from the first step prevents closeTestingConnections from running. This is a new risk
introduced by adding extra async cleanup logic to the after-hook.

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[39-52]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[194-204]

Agent prompt

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

## Issue description
If resetting CockroachDB cluster settings fails in the fallback suite’s `after()` hook, `closeTestingConnections()` is skipped.
### Issue Context
The after-hook performs multiple awaited operations; cleanup should be resilient so connections are always closed.
### Fix Focus Areas
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[194-204]
### Proposed fix
Wrap the reset block in a `try { ... } finally { await closeTestingConnections(dataSources) }` so connections are closed even if `setIsolationClusterSettings` throws/rejects.

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

Description

The CockroachDB isolation tests hardcode the expected effective isolation level for “default
settings” but do not set/read the cluster settings that control CockroachDB’s fallback behavior,
making the assertions environment-dependent and prone to failure (e.g., REPEATABLE READ can run as
SERIALIZABLE when the repeatable-read setting is disabled). This can break CI or local runs
depending on the cluster’s configuration.

Code

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[R29-37]

+const getExpectedIsolationForDefaultSettings = (
+    requestedIsolationLevel: string,
+) => {
+    if (requestedIsolationLevel === "READ UNCOMMITTED") {
+        return "READ COMMITTED"
+    }
+
+    return requestedIsolationLevel
+}

Evidence

getExpectedIsolationForDefaultSettings only remaps READ UNCOMMITTED→READ COMMITTED and otherwise
assumes the requested level is the effective level; this is then used to assert the server’s
effective isolation in both the “supported” and “defined in data source” suites. However, the PR’s
own CockroachDB docs (and the test file’s own fallbackCases) state that the effective isolation
can change based on sql.txn.read_committed_isolation.enabled and
sql.txn.repeatable_read_isolation.enabled, which these suites do not control before asserting.

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[29-37]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[66-83]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[164-175]
test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[202-270]
docs/docs/transactions.mdx[63-76]

Agent prompt

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

## Issue description
`cockroachdb-isolation.test.ts` asserts the effective isolation level returned by `SHOW TRANSACTION ISOLATION LEVEL`, but the expected values depend on CockroachDB cluster settings. The tests currently don’t set/read those settings for the “supported” and “defined in data source” suites, so results can vary by environment.
### Issue Context
CockroachDB may map requested weaker levels to stronger ones depending on:
- `sql.txn.read_committed_isolation.enabled`
- `sql.txn.repeatable_read_isolation.enabled`
The test file already encodes this dependency in `fallbackCases`, but other suites still assume a fixed default mapping.
### Fix Focus Areas
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[29-37]
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[66-83]
- test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[164-175]
### Suggested fix
Choose one deterministic approach:
1) **Set known cluster settings** in `before()` hooks for the “supported” and “defined in data source” suites (e.g., enable `readCommitted` and `repeatableRead`) and update expected mapping accordingly.
OR
2) **Compute expected effective isolation dynamically** by querying current cluster settings (e.g., `SHOW CLUSTER SETTING ...`) and using the same mapping rules as `fallbackCases` for assertions.
Either way, avoid assuming “default settings” without enforcing or reading them.

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

Description

The CockroachDB isolation fallback tests change cluster-wide settings via SET CLUSTER SETTING ...
and never reset them, leaving sql.txn.repeatable_read_isolation.enabled disabled after the suite
completes. This can change behavior of later CockroachDB tests against the same cluster and make the
test run order-dependent/flaky.

Code

test/functional/transaction/isolation-level/cockroachdb-isolation.test.ts[R257-287]

+                name: "REPEATABLE READ -> SERIALIZABLE when repeatable read setting is disabled",
+                requestedIsolationLevel: "REPEATABLE READ",
+                settings: {
+                    readCommitted: true,
+                    repeatableRead: false,
+                },
+                expectedIsolationLevel: "SERIALIZABLE",
+            },
+        ]
+
+        for (const testCase of fallbackCases) {
+            it(testCase.name, () =>
+                Promise.all(
+                    dataSources.map(async (dataSource) => {
+                        await setIsolationClusterSettings(
+                            dataSource,
+                            testCase.settings,
+                        )
+
+                        await dataSource.manager.transaction(
+                            testCase.requestedIsolationLevel,
+                            async (entityManager) => {
+                                await getCurrentTransactionLevelAndAssert(
+                                    entityManager,
+                                    testCase.expectedIsolationLevel,
+                                )
+                            },
+                        )
+                    }),
+                ),
+            )

Evidence

The fallback suite’s last case sets repeatableRead: false, and each case applies the settings with
SET CLUSTER SETTING; there is no after/afterEach hook to restore the previous values.
Separate...