fix: detect findUniqueOrThrow as a compactable findUnique operation

[hayes]

Currently findUniqueOrThrow callas are not being compacted/optimized like findUnique calls. As far as I can tell, there is no reason this would be intentional, and many other checks for isFindUnique currently do something equivelent to name.startsWith('findUnique')

[CLAassistant]

All committers have signed the CLA.

[SevInf]

Hi @hayes.
Not compacting findUniqueOrThrow at the moment is intentional (#3458, prisma/prisma#16548), as it would involve more work then just batching the queries into single SQL statement. I believe this PR just brings prisma/prisma#16548 back and does not actually fix the batching, (see queries::batch::select_one_singular::singular_batch::repro_16548 test).

We will be willing to merge proper fix for *OrThrow variant batching, but this PR needs more work at the moment.

[codspeed-hq]

CodSpeed Performance Report

Merging #4014 hayes:main (8781777) will not alter performances.

Summary

🔥 0 improvements
❌ 0 regressions
✅ 11 untouched benchmarks

🆕 0 new benchmarks
⁉️ 0 dropped benchmarks

[hayes]

@SevInf thanks for taking a look, and sorry for opening the PR without actually getting my tests running locally.

I looked at this a bit more today, and the proper fix doesn't seem overly complicated, but this is my first time looking at prisma-engine, so I may be missing some things.

I've updated the PR with a basic implementation to test that my understanding is correct, but there are a few things I could use some help figuring out:

1. When mapping the findMany back to the findUniqueOrThrow payloads, we need to insert an error response, but I was having a hard time figuring out how to generate the correct error here (lots of wrapping and indirection in the various error types/enums).
   • I didn't try to hard to verify this, but it looks like findUnique with rejectOnUnauthorized would just return null, and create the error in the client, I assume that for findUniqueOrThrow the error message is intended to come from the engine instead of the client?
2. In CompactDocument we need to track if the original queries were using findUnique or findUniqueOrThrow for 2 reasons: we need to have the single field name to map back to, and we need to know if we should insert an error or just a null result when a result is missing
   • I am currently assuming that findUniqueOrThrow and findUnique are batched separately. The batch ids generated, I think will be different between these 2 methods, so batching these together would also require client changes
   • tracking this per query rather than per batch would add more complexity, and not sure if this would be worth the added complexity
   • This is currently tracked as a suffix string. This feels a bit hacky, but I have not written a ton of rust, and am not familiar enough with this code base to know the best way to track that state
3. The regression test for the issue you mentioned explicitly check that things shouldn't be batched. I think it should be safe to update the test to allow batching, as long as the response doesn't change (it currently does because the errors are not being generated correctly), but want to confirm my understanding of the issue was correct before changing that

[miguelff]

@hayes I'm looking into the updated patch today and your questions and will provide feedback soon. Thank you very much!

[miguelff]

@hayes, I answered your questions and suggested a few changes to your (already promising) patch in hayes#1

[hayes]

Thanks @miguelff, merged your changes, let me know if there is anything else you need me to do

[miguelff]

Superseded by #4019. I'm taking it from there.