Bug description

Regression from Rust engine. When one specifies a transaction timeout for a lengthy transaction:

PRISMA.$transaction((tx) => tx.model.createMany(data), {timeout: 1000 * 60 * 5})

Any individual request within that transaction will still obey node-mssql's config.requestTimeout (default 15 seconds).

... and fail with error: "Timeout: Request failed to complete in 15000ms".

This config can be specified when constructing the PrismaClient singleton, but this means all connections will have this extended "requestTimeout" specification - I wish to extend the timeout in a specific set of circumstances. This represents a regression from the Rust engine where no such additional timeout was an effective constraint, and the timeout I specified per transaction was the limiting factor.

Severity

⚠️ Major: Breaks core functionality (e.g., migrations fail)

Reproduction

While using the new TS engine with the "adapter-mssql" adapter, create a transaction of any arbitrary length > 15000ms which contains a, for example, createMany request which takes longer than 15 seconds.

Expected vs. Actual Behavior

Expected: Prisma Client's $transaction.options.timeout parameter is the limiting factor in deciding how long requests can be.
Actual: node-mssql's requestTimeout is actually the limiting factor, if it is less than the transaction timeout

Frequency

Consistently reproducible

Does this occur in development or production?

Both development and production

Is this a regression?

Yes. Works as expected in old Rust engine; doesn't work with new TS engine / MS SQL adapter

Workaround

Prisma Schema & Queries

// Add relevant schema.prisma snippet

// Add relevant Prisma Client query

Prisma Config

// Add your `prisma.config.ts`

Logs & Debug Info

// Debug logs here

Environment & Setup

• OS:
• Database:
• Node.js version:

Prisma Version

// Prisma version output