packages/adapter-mariadb/src/mariadb.ts (1)

136-150: ⚠️ Potential issue | 🟡 Minor

Use JSDoc here, and keep the database docs truthful.

/* ... */ will not be picked up as documentation for this exported type, and the text on Lines 138-139 promises connection-string inference that this file never performs—getConnectionInfo() only reads this.mariadbOptions?.database on Line 172.

📝 Suggested doc update

+/**
+ * Adapter-specific options that are not forwarded to the MariaDB pool.
+ */
 export type PrismaMariadbOptions = {
-  /*
-   * The name of the database to connect to. If not provided, the adapter will attempt to infer
-   * it from the connection string.
-   */
+  /** Database name reported through `getConnectionInfo()`. */
   database?: string
-  /*
-   * Whether to use the text protocol for all queries. If false or not set, the adapter will use
-   * the binary protocol.
-   */
+  /**
+   * Use the driver's text protocol (`query`) instead of the binary protocol (`execute`).
+   * This avoids prepared statements, but opts into the text-protocol edge cases.
+   */
   useTextProtocol?: boolean
-  /*
-   * The callback to be attached to the connection's 'error' event.
-   */
+  /** Callback attached to transaction connection `error` events. */
   onConnectionError?: (err: mariadb.SqlError) => void
 }

As per coding guidelines, "Use documentation comments for exported items in TypeScript/JavaScript files".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/adapter-mariadb/src/mariadb.ts` around lines 136 - 150, Replace the
/* ... */ comments on the exported type PrismaMariadbOptions with JSDoc /** ...
*/ comments and make the `database` description truthful (state that it is
optional and used directly by getConnectionInfo() / read from
this.mariadbOptions?.database rather than inferred from a connection string);
also add JSDoc entries for `useTextProtocol` and `onConnectionError` (mention it
is a callback receiving mariadb.SqlError) so the exported type has proper
tooling-visible documentation and accurate behavior descriptions.

packages/adapter-mariadb/src/mariadb.test.ts (1)

79-87: ⚠️ Potential issue | 🟠 Major

vi.mock() inside beforeAll() is still hoisted file-wide.

Vitest hoists vi.mock() calls, so the credential-sanitization case at Lines 37-52 still will not hit the real MariaDB parser; once factory.connect() resolves against the mocked module, Lines 47-50 only observe the test's own failure path. Use vi.spyOn(mariadb, 'createPool') inside these constructor tests, or move them to a separate file that can safely mock the module.

🧪 Safer test shape

-import { describe, expect, test, vi, beforeAll, afterAll } from 'vitest'
+import { afterEach, describe, expect, test, vi } from 'vitest'

 describe('PrismaMariaDbAdapterFactory constructor', () => {
-  beforeAll(() => {
-    vi.mock('mariadb', () => ({
-      createPool: vi.fn(),
-    }))
-  })
-
-  afterAll(() => {
-    vi.doUnmock('mariadb')
+  afterEach(() => {
+    vi.restoreAllMocks()
   })

-    const mockCreatePool = vi.mocked(mariadb.createPool)
-    mockCreatePool.mockReturnValue({
+    const mockCreatePool = vi.spyOn(mariadb, 'createPool').mockReturnValue({
       query: vi.fn().mockResolvedValue([['8.0.13']]),
       end: vi.fn(),
     } as unknown as mariadb.Pool)

Does Vitest hoist `vi.mock()` calls even when they are declared inside `beforeAll()` or a `describe()` block?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/adapter-mariadb/src/mariadb.test.ts` around lines 79 - 87, The
vi.mock call in mariadb.test.ts is hoisted so the constructor tests never
exercise the real MariaDB parser; replace the file-wide vi.mock in
beforeAll/afterAll with a per-test spy or isolate the tests: inside the
constructor/credential-sanitization tests use vi.spyOn(require('mariadb'),
'createPool') (or import mariadb and spyOn(mariadb, 'createPool')) to stub
behavior only for that test, or move those constructor tests into a separate
file where you can safely mock the module; ensure factory.connect and the code
paths around the parser/credential handling now run against the real module
unless explicitly spied.

packages/adapter-mariadb/src/mariadb.test.ts (1)

79-87: ⚠️ Potential issue | 🟠 Major

vi.mock() here still affects the whole module.

Vitest documents that vi.mock() is hoisted wherever it appears—even inside hooks—and that vi.doMock() only affects subsequent dynamic imports. With the static import * as mariadb at Line 1, this beforeAll block does not keep the mock local to this suite, so the credential-sanitization test above can still exercise the mocked driver instead of the real parser. Use vi.spyOn(mariadb, 'createPool') here, or switch to vi.doMock() plus a dynamic import of the code under test. (vitest.dev)

🔧 One way to keep the mock local to this suite

-import { describe, expect, test, vi, beforeAll, afterAll } from 'vitest'
+import { afterAll, afterEach, describe, expect, test, vi } from 'vitest'

 describe('PrismaMariaDbAdapterFactory constructor', () => {
-  beforeAll(() => {
-    vi.mock('mariadb', () => ({
-      createPool: vi.fn(),
-    }))
-  })
+  const mockCreatePool = vi.spyOn(mariadb, 'createPool')
+
+  afterEach(() => {
+    mockCreatePool.mockReset()
+  })

   afterAll(() => {
-    vi.doUnmock('mariadb')
+    mockCreatePool.mockRestore()
   })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/adapter-mariadb/src/mariadb.test.ts` around lines 79 - 87, The test
uses vi.mock('mariadb') inside beforeAll which is hoisted and thus affects the
statically imported mariadb module globally; replace that with a local spy or a
dynamic mock: either change the setup to vi.spyOn(mariadb, 'createPool')
(referencing the imported mariadb and its createPool) so only the createPool
function is stubbed for this suite, or switch to vi.doMock('mariadb') and
perform a dynamic import of the code under test so the mock only applies to this
suite (adjust test file to import the module-under-test after calling
vi.doMock).

packages/adapter-mariadb/src/mariadb.test.ts (1)

87-105: 🧹 Nitpick | 🔵 Trivial

Replace the string-indexed flagToMethod lookup with typed cases.

String(!!flag) widens the key to string, so method stops being the literal union 'query' | 'execute' and the indexed assertions lose type safety. Build the test.each table with explicit typed entries instead.

♻️ Possible fix

-  const flagToMethod = {
-    true: 'query',
-    false: 'execute',
-  }
-
-  test.each([false, undefined, true].map((flag) => ({ flag, method: flagToMethod[String(!!flag)] })))(
+  test.each([
+    { flag: false, method: 'execute' as const, otherMethod: 'query' as const },
+    { flag: undefined, method: 'execute' as const, otherMethod: 'query' as const },
+    { flag: true, method: 'query' as const, otherMethod: 'execute' as const },
+  ])(
     'should use client.$method when useTextProtocol is $flag',
-    async ({ flag, method }) => {
+    async ({ flag, method, otherMethod }) => {
       const mockClient = {
         execute: vi.fn().mockResolvedValue({ meta: [], affectedRows: 1 }),
         query: vi.fn().mockResolvedValue({ meta: [], affectedRows: 1 }),
       } as unknown as mariadb.Pool

       const adapter = new PrismaMariaDbAdapter(mockClient, { supportsRelationJoins: true }, { useTextProtocol: flag })
       await adapter.executeRaw({ sql: 'SELECT 1', args: [], argTypes: [] })
       expect(mockClient[method]).toHaveBeenCalledWith(expect.objectContaining({ sql: 'SELECT 1' }), [])

-      expect(mockClient[flagToMethod[String(!flag)]]).not.toHaveBeenCalled()
+      expect(mockClient[otherMethod]).not.toHaveBeenCalled()
     },
   )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/adapter-mariadb/src/mariadb.test.ts` around lines 87 - 105, The test
uses a string-indexed lookup (flagToMethod[String(!!flag)]) which widens the key
to string and loses the literal type of method; change the test data to a typed
table of explicit entries (e.g., [{ flag: false, method: 'execute' }, { flag:
undefined, method: 'execute' }, { flag: true, method: 'query' }]) instead of
using String(!!flag) and flagToMethod, then update the test.each call to iterate
that typed array so method is typed as 'query' | 'execute' and the assertions
against mockClient[method] and mockClient[flagToMethod[String(!flag)]] remain
type-safe when calling PrismaMariaDbAdapter(...).executeRaw and verifying
mockClient calls.

packages/adapter-mariadb/src/mariadb.ts (1)

232-236: ⚠️ Potential issue | 🟠 Major

Remove the raw parse error from this debug path.

Line 233 logs the full URL parse exception object. For malformed DSNs, that object can include the original connection string, so credentials can still leak before connect() reaches its sanitized error handling. Log a constant/redacted message here instead of the raw error.

🛡️ Minimal fix

-      } catch (error) {
-        debug('Error parsing connection string: %O', error)
+      } catch {
+        debug('Error parsing connection string')
         // If we can't parse the connection string, use it as-is and let the driver fail with
         // its own error.
         this.#config = config
       }

In Node.js, when `new URL()` throws `ERR_INVALID_URL`, does the thrown error expose the original input string via an `input` property?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/adapter-mariadb/src/mariadb.ts` around lines 232 - 236, In the catch
block that currently calls debug('Error parsing connection string: %O', error)
(inside the URL/DSN parsing logic in mariadb.ts), remove the raw error object
from the log and replace it with a constant/redacted message (e.g., "Error
parsing connection string; using raw DSN") so the original connection string or
credentials cannot be leaked; keep the fallback assignment this.#config = config
and do not change the subsequent behavior of connect() or its sanitized error
handling.