Bug: D1 One-to-Many Relation INSERTs fail with The required connected records were not found. when using indices

[hrueger]

Bug description

When creating rows with a one-to-many relation and using manually added @@indexs, the query fails with:

The required connected records were not found. Expected 1 records to be connected after connect operation on one-to-many relation 'OrderToTicket', found 2.

I believe this happens due to D1 returning the number of rows written, including writes to index tables... not actual written data rows.

How to reproduce

See the reproduction here: https://github.com/hrueger/prisma-23902. Basically, you need

• a schema with a one-to-many relation
• a manual index on the relation's id column
• a query connecting an item

Expected behavior

It should connect the record.
I think I found two possible ways:

1. count the indices and substract that number from the rows_written or
2. Skip that check for D1

Prisma information

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["driverAdapters"]
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model User {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  email     String   @unique
  name      String?
  posts     Post[]
}

model Post {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  title     String
  author    User?    @relation(fields: [authorId], references: [id])
  authorId  Int?

  @@index([authorId])
}

const post = await prisma.post.create({
		data: {
			title: "Hello World" + Math.random(),
		}
	});
    const user = await prisma.user.create({
		data: {
			email: Math.random() + "test@test.de",
			name: "Test",
			posts: {
				connect: {
					id: post.id
				}
			}
		}
	});

Environment & setup

• OS: macOS
• Database: Cloudflare D1
• Node.js version: v21.6.1

Prisma Version

prisma                  : 5.12.1
@prisma/client          : 5.12.1
Computed binaryTarget   : darwin-arm64
Operating System        : darwin
Architecture            : arm64
Node.js                 : v21.6.1
Query Engine (Node-API) : libquery-engine 473ed3124229e22d881cb7addf559799debae1ab (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Schema Engine           : schema-engine-cli 473ed3124229e22d881cb7addf559799debae1ab (at node_modules/@prisma/engines/schema-engine-darwin-arm64)
Schema Wasm             : @prisma/prisma-schema-wasm 5.12.0-21.473ed3124229e22d881cb7addf559799debae1ab
Default Engines Hash    : 473ed3124229e22d881cb7addf559799debae1ab
Studio                  : 0.499.0
Preview Features        : driverAdapters

[janpio]

Can reproduce with the provided https://github.com/hrueger/prisma-23902:

[wrangler:err] PrismaClientKnownRequestError: 
Invalid `prisma.user.create()` invocation:


The required connected records were not found. Expected 1 records to be connected after connect operation on one-to-many relation 'PostToUser', found 2.
    at or.handleRequestError (file:///workspace/prisma-23902/node_modules/@prisma/client/runtime/wasm.js:22:7128)
    at or.handleAndLogRequestError (file:///workspace/prisma-23902/node_modules/@prisma/client/runtime/wasm.js:22:6462)
    at or.request (file:///workspace/prisma-23902/node_modules/@prisma/client/runtime/wasm.js:22:6176)
    at async f (file:///workspace/prisma-23902/node_modules/@prisma/client/runtime/wasm.js:27:11094)
    at async Object.fetch (file:///workspace/prisma-23902/src/index.ts:18:18)
    at async jsonError (file:///workspace/prisma-23902/node_modules/wrangler/templates/middleware/middleware-miniflare3-json-error.ts:22:10)
    at async drainBody (file:///workspace/prisma-23902/node_modules/wrangler/templates/middleware/middleware-ensure-req-body-drained.ts:5:10)
[wrangler:inf] GET / 500 Internal Server Error (153ms)

I believe this happens due to D1 returning the number of rows written, including writes to index tables... not actual written data rows.

This theory sounds plausible and should be investigated.