Inserting >1MB Single Record Data Yields 408 Request Timeout

[dkindlund]

Hi @tea-artist ,

When performing an HTTP PATCH to update a single record in self-hosted Teable, I'm consistently getting 408 request timeout errors that look like this:

TimeoutHttpException: Request timeout
    at Proxy.<anonymous> (/app/community/packages/db-main-prisma/dist/prisma.service.js:25:35)
    at async ReferenceService.getRecordMap (/app/enterprise/backend-ee/dist/index.js:60146:28)
    at async ReferenceService.getRecordMapBatch (/app/enterprise/backend-ee/dist/index.js:60132:16)
    at async ReferenceService.calculateLinkRelatedRecords (/app/enterprise/backend-ee/dist/index.js:59602:38)
    at async ReferenceService.calculate (/app/enterprise/backend-ee/dist/index.js:59713:17)
    at async ReferenceService.calculateRecordData (/app/enterprise/backend-ee/dist/index.js:59688:9)
    at async ReferenceService.calculateOpsMap (/app/enterprise/backend-ee/dist/index.js:59567:9)
    at async RecordCalculateService.calculate (/app/enterprise/backend-ee/dist/index.js:120129:9)
    at async RecordCalculateService.calculateUpdatedRecord (/app/enterprise/backend-ee/dist/index.js:120160:9)
    at async /app/enterprise/backend-ee/dist/index.js:125847:20
    at async /app/community/packages/db-main-prisma/dist/prisma.service.js:89:28
    at async Proxy._transactionWithCallback (/app/node_modules/.pnpm/@prisma+client@6.2.1_prisma@6.2.1/node_modules/@prisma/client/runtime/library.js:130:7984)
    at async /app/community/packages/db-main-prisma/dist/prisma.service.js:82:22
    at async Proxy.$tx (/app/community/packages/db-main-prisma/dist/prisma.service.js:81:9)
    at async RecordOpenApiService.updateRecords (/app/enterprise/backend-ee/dist/index.js:125835:30)
    at async descriptor.value (/app/enterprise/backend-ee/dist/index.js:126169:32)

The data being sent in the HTTP payload is about 1MB in size.

I get this error after about 5 seconds from the start of the HTTP request.

I believe the reason why this is happening is that the resultant DB insert operation is taking longer than 5 seconds to complete, and Prisma is terminating the operation after the default 5 seconds, as listed here:

teable/packages/db-main-prisma/src/prisma.service.ts

Lines 82 to 88 in cd0099f

	async $tx<R = unknown>(
	fn: (prisma: Prisma.TransactionClient) => Promise<R>,
	options?: {
	maxWait?: number;
	timeout?: number;
	isolationLevel?: Prisma.TransactionIsolationLevel;
	}

Currently, because this is a updating a single record via HTTP PATCH, the BIG_TRANSACTION_TIMEOUT does NOT apply.

Can we please either:

1. Update the HTTP PATCH for single records to ALSO use the BIG_TRANSACTION_TIMEOUT logic?
   OR
2. Can we get a NEW environment variable to override the default 5 second Prisma timeout for HTTP PATCH operations?

[dkindlund]

@tea-artist , please see this relevant information regarding the default 5 second timeout in Prisma:

prisma/prisma#26807.

[dkindlund]

The current workaround here is to split the update across multiple HTTP PATCH operations -- only updating about half the fields in each request which then results in 2 different transactions.

[dkindlund]

It looks like this problem also happens a lot if you're inserting a record into a table with more than about 4 calculated (formula) fields.

[dkindlund]

The solution here might be to wrap every Prisma transaction with a configurable timeout.

For example, I see some long running operations are wrapped like this:

teable/apps/nestjs-backend/src/features/table/table-duplicate.service.ts

Lines 113 to 117 in cd0099f

	},
	{
	timeout: this.thresholdConfig.bigTransactionTimeout,
	}
	);

Similarly, if the updateRecords prisma transaction were also wrapped in equivalent timeout logic, then I think that would solve this problem:

teable/apps/nestjs-backend/src/features/record/open-api/record-open-api.service.ts

Lines 292 to 322 in cd0099f

	const cellContexts = await this.prismaService.$tx(async () => {
	if (order != null) {
	const { viewId, anchorId, position } = order;
	await this.viewOpenApiService.updateRecordOrders(tableId, viewId, {
	anchorId,
	position,
	recordIds: records.map((r) => r.id),
	});
	}
	// validate cellValue and typecast
	const typecastRecords = await this.validateFieldsAndTypecast(
	tableId,
	records,
	fieldKeyType,
	typecast
	);
	const preparedRecords = await this.systemFieldService.getModifiedSystemOpsMap(
	tableId,
	fieldKeyType,
	typecastRecords
	);
	return await this.recordCalculateService.calculateUpdatedRecord(
	tableId,
	fieldKeyType,
	preparedRecords
	);
	});

The same fix can be applied to createRecord operations, too.

[tea-artist]

You can change env params like this
PRISMA_DATABASE_URL=postgresql://user:password@host:port/database?connect_timeout=30

[dkindlund]

Hi @tea-artist,

Thanks for the suggestion to use connect_timeout, but it did not solve our TimeoutHttpException issue. We're still seeing 408 errors. I also tried using the statement_timeout parameter as well, and that didn't help either.

What connect_timeout Actually Controls

The connect_timeout parameter only controls how long the client waits to establish the initial TCP connection and authentication with the PostgreSQL server. According to the PostgreSQL documentation, this timeout specifically governs the connection establishment phase before any queries are executed.

Why It Won't Help Here

Our TimeoutHttpException is occurring after the connection is already established, during complex database operations within a Prisma transaction:

TimeoutHttpException: Request timeout
    at Proxy.<anonymous> (/app/community/packages/db-main-prisma/dist/prisma.service.js:25:35)
    at async ReferenceService.getRecordMap (...)

The error happens during reference calculations that exceed Prisma's hardcoded 5-second transaction timeout, not during the initial connection handshake phase that connect_timeout addresses. There is no way to fix this problem at the PostgreSQL layer.

What We Actually Need

The root issue is in Teable's PrismaService.$tx method, which uses Prisma's default transaction timeouts:

• maxWait: 2000ms (to acquire connection from pool)
• timeout: 5000ms (for transaction execution)

Since Teable doesn't expose these as configurable environment variables, we need to modify the transaction timeout logic directly in the codebase.

[dkindlund]

@tea-artist , one idea here is to define a SMALL_TRANSACTION_TIMEOUT mechanism that essentially covers all other Prisma transactions that are not already covered by BIG_TRANSACTION_TIMEOUT. That way, all possible transactions have an adjustable timeout mechanism in the future.

Currently, the BIG_TRANSACTIONS_TIMEOUT mechanism can be found in the following locations in the code:

#	Prisma Transaction Call Site & Function (File + Function/Line)	BIG_TRANSACTION_TIMEOUT Applied?
1	apps/nestjs-backend/src/features/record/open-api/record-open-api.service.ts:multipleCreateRecords	Yes
2	apps/nestjs-backend/src/features/table/open-api/table-open-api.service.ts (multiple calls)	Yes
3	apps/nestjs-backend/src/features/undo-redo/operations/delete-records.operation.ts (delete logic)	Yes
4	apps/nestjs-backend/src/features/field/open-api/field-open-api.service.ts (field creation logic)	Yes
5	apps/nestjs-backend/src/features/trash/trash.service.ts (restore/delete logic)	Yes
6	apps/nestjs-backend/src/features/trash/listener/table-trash.listener.ts (restore logic)	Yes
7	apps/nestjs-backend/src/features/table/table-index.service.ts:toggleSearchIndex, repairIndex	Yes
8	apps/nestjs-backend/test/performance.e2e-spec.ts (large batch operations, sometimes hardcoded)	Sometimes (sometimes hardcoded timeout)
9	apps/nestjs-backend/test/dead-lock.e2e-spec.ts:transaction1, transaction2 (test, hardcoded 5000)	No (uses hardcoded timeout)
10	apps/nestjs-backend/src/features/record/open-api/record-open-api.service.ts:createRecordsOnlySql	No (no timeout specified)
11	apps/nestjs-backend/src/features/calculation/batch.service.ts:fetchRawData	No (txClient direct, no timeout)
12	apps/nestjs-backend/src/features/table/table-index.service.ts:createSearchFieldSingleIndex,	No (txClient direct, no timeout)
13	apps/nestjs-backend/src/features/table/table-index.service.ts:deleteSearchFieldIndex, updateSearchFieldIndexName, getIndexInfo, getAbnormalTableIndex	No (txClient direct, no timeout)
14	packages/db-main-prisma/src/prisma.service.ts:$tx (default signature, called without timeout)	No
15	Any location using txClient().$executeRawUnsafe or $queryRawUnsafe directly	No

Legend:

• "Yes": Transaction is called with { timeout: this.thresholdConfig.bigTransactionTimeout }.
• "No": Transaction does not specify BIG_TRANSACTION_TIMEOUT (either no timeout, or a different hardcoded value, or direct txClient usage).

How this was constructed:

• Locations were sourced from all referenced context, including configuration, service, operation, listener, and test files.
• Calls to $tx or $transaction with { timeout: this.thresholdConfig.bigTransactionTimeout } are marked "Yes".
• Calls to $tx, $transaction, or txClient methods with no timeout or different timeout are marked "No".

Exhaustive clinical summary:

• All bulk/batch/complex operations (create, delete, field ops, trash ops, table ops, index ops) use BIG_TRANSACTION_TIMEOUT.
• All simple, single-record, or direct txClient operations do NOT use BIG_TRANSACTION_TIMEOUT.
• Test transactions typically use a small hardcoded timeout (e.g., 5000 ms).

[dkindlund]

Locations for Applying SMALL_TRANSACTION_TIMEOUT in teableio/teable

Assumption:
SMALL_TRANSACTION_TIMEOUT should be applied to every Prisma transaction that is NOT already covered by BIG_TRANSACTION_TIMEOUT (i.e., does not use { timeout: this.thresholdConfig.bigTransactionTimeout }).

Below is an exhaustive, clinically specific list of code paths (file + function or context) where Prisma transactions occur without BIG_TRANSACTION_TIMEOUT and where the new SMALL_TRANSACTION_TIMEOUT mechanism would need to be applied:

---

#	File Path	Function/Context	Type/Call	Timeout Currently?
1	apps/nestjs-backend/src/features/record/open-api/record-open-api.service.ts	createRecordsOnlySql	this.prismaService.$tx	None
2	apps/nestjs-backend/test/dead-lock.e2e-spec.ts	transaction1, transaction2	prismaService.$transaction	Hardcoded (5000)
3	apps/nestjs-backend/src/features/calculation/batch.service.ts	fetchRawData	prismaService.txClient().$queryRawUnsafe	None
4	apps/nestjs-backend/src/features/table/table-index.service.ts	createSearchFieldSingleIndex	prismaService.txClient().$executeRawUnsafe	None
5	apps/nestjs-backend/src/features/table/table-index.service.ts	deleteSearchFieldIndex	prismaService.txClient().$executeRawUnsafe	None
6	apps/nestjs-backend/src/features/table/table-index.service.ts	updateSearchFieldIndexName	prismaService.txClient().$executeRawUnsafe	None
7	apps/nestjs-backend/src/features/table/table-index.service.ts	getIndexInfo, getAbnormalTableIndex	prismaService.txClient().$queryRawUnsafe	None
8	packages/db-main-prisma/src/prisma.service.ts	$tx (default signature, used anywhere without timeout)	Various this.prismaService.$tx calls	None
9	Any other direct txClient().$executeRawUnsafe or $queryRawUnsafe usage	Throughout backend code	Direct txClient calls	None

---

Detailed Example Code Paths

1. apps/nestjs-backend/src/features/record/open-api/record-open-api.service.ts

async createRecordsOnlySql(tableId: string, createRecordsRo: ICreateRecordsRo): Promise<void> {
  await this.prismaService.$tx(async () => {
    return await this.createPureRecords(tableId, createRecordsRo);
  }); // <-- Would need SMALL_TRANSACTION_TIMEOUT
}

---

2. apps/nestjs-backend/test/dead-lock.e2e-spec.ts

await prismaService.$transaction(
  async (tx) => { ... },
  { timeout: 5000 } // <-- Replace with SMALL_TRANSACTION_TIMEOUT
);

---

3. apps/nestjs-backend/src/features/calculation/batch.service.ts

return this.prismaService.txClient().$queryRawUnsafe<...>(querySql); // <-- Would need SMALL_TRANSACTION_TIMEOUT if wrapped in $tx

---

4–7. apps/nestjs-backend/src/features/table/table-index.service.ts

All direct txClient().$executeRawUnsafe or $queryRawUnsafe calls not inside a BIG_TRANSACTION_TIMEOUT wrapper:

await this.prismaService.txClient().$executeRawUnsafe(sql); 
await this.prismaService.txClient().$queryRawUnsafe<unknown[]>(sql);

---

8. packages/db-main-prisma/src/prisma.service.ts

Any use of $tx without a timeout argument (in every consumer):

await this.$tx(fn); // <-- Would need SMALL_TRANSACTION_TIMEOUT if fn is not bulk/big

---

9. Any location using txClient().$executeRawUnsafe or $queryRawUnsafe directly

Example:

await prismaService.txClient().$executeRawUnsafe(sql); // <-- Would need SMALL_TRANSACTION_TIMEOUT
await prismaService.txClient().$queryRawUnsafe(sql);   // <-- Would need SMALL_TRANSACTION_TIMEOUT

---

Summary Table

File Path	Function/Context	Transaction Call
apps/nestjs-backend/src/features/record/open-api/record-open-api.service.ts	createRecordsOnlySql	$tx (no timeout)
apps/nestjs-backend/test/dead-lock.e2e-spec.ts	transaction1, transaction2	$transaction (hardcoded timeout)
apps/nestjs-backend/src/features/calculation/batch.service.ts	fetchRawData	txClient().$queryRawUnsafe
apps/nestjs-backend/src/features/table/table-index.service.ts	createSearchFieldSingleIndex	txClient().$executeRawUnsafe
apps/nestjs-backend/src/features/table/table-index.service.ts	deleteSearchFieldIndex	txClient().$executeRawUnsafe
apps/nestjs-backend/src/features/table/table-index.service.ts	updateSearchFieldIndexName	txClient().$executeRawUnsafe
apps/nestjs-backend/src/features/table/table-index.service.ts	getIndexInfo, getAbnormalTableIndex	txClient().$queryRawUnsafe
packages/db-main-prisma/src/prisma.service.ts	$tx used without explicit timeout	$tx
(global)	Any direct txClient().$executeRawUnsafe usage	txClient().$executeRawUnsafe
(global)	Any direct txClient().$queryRawUnsafe usage	txClient().$queryRawUnsafe

---

Clinical Guidance:
To implement SMALL_TRANSACTION_TIMEOUT, update every location listed above to add { timeout: SMALL_TRANSACTION_TIMEOUT } to the options object for Prisma transaction calls that do not already use BIG_TRANSACTION_TIMEOUT.

[dkindlund]

Hi @tea-artist , this problem appears to also exist when switching the value of a record's linked field from one value to a different one. Let me explain:

Assume you have a Teable base with 2 tables:

1st Table: Articles
2nd Table: Readers

We set up the relationship such that 1 Article record can only be ever assigned 1 Reader record, but a single Reader record can be assigned many Article records (a one-to-many relationship).

In the Readers table, we have about 6 formula fields that calculate rollup stats like:
a) How many Articles of type "X" were assigned to a Reader?
b) How many Articles of type "Y" were assigned to a Reader?
c) How many Articles in the past week were assigned to a Reader?
d) How many Articles in the past 2 weeks were assigned to a Reader?
e) How many Articles in the past month were assigned to a Reader?
f) How many Articles in the past 6 months were assigned to a Reader?

On average, a single Reader might be linked to 30 to 40 Article records.

Now, sometimes, we need to switch an Article's linked Reader. When we do that, we attempt to copy the new Reader value and paste that new value into the cell within the Article's record corresponding to the Reader field.

When we do that, we almost always get HTTP 408 errors.

This is because Teable attempts to perform in batch sequence:

1. Clear the old Reader value from the Article record.
2. Recalculate all the formulas listed from (a) through (f).
3. Then update the Article record with the new Reader value.
4. Recalculate all the formulas listed from (a) through (f).

And because ALL of these operations are running within a single Prisma transaction, it's impossible for Teable to complete those operations within 5 seconds or less.

That's why a 408 timeout is getting thrown.

Therefore, until this issue is resolved, it's literally impossible to use Teable with 2 or more linked tables where one of those tables has more than about 2-3 formulas.

Does that help explain the severity of this issue, @tea-artist ? Thanks.

[tea-artist]

PR #1694 by @nichenqin will significantly enhance the performance of the computing(formula, lookup, rollup) process. It should be possible to reduce the processing time to within 5 seconds.

[dkindlund]

Hi @tea-artist , thanks for the update. Please make sure @nichenqin tests their improvements against two linked tables where a single record in Table A has 100+ links to 100+ different records in Table B, and you're then attempting to add an additional 50 new links to that same record -- that scenario seems to reliably cause Teable to throw 408 errors.