Transactions unexpected behavior (Prisma)

Hello, I have been working on setting up ps-http-sim in front of our MySQL docker container for our local development setup to give better parity with PlanetScale's actual DBs. Everything seems to be working great except that I am encountering strange errors with some of our transactional-based operations. The two unexpected behaviors I am seeing are:

1. Transaction operations executing out of order. In many areas of our codebase we create an object, and then reuse that object later in the transaction. For example:

await prisma.$transaction([
  prisma.user.create({ data: { id, ... } }),
  prisma.foo.create(...),
  prisma.user.update({ where: { id }, data: { ... } })
])

When using ps-http-sim I often, but not always, run into the error: An operation failed because it depends on one or more records that were required but not found. No record was found for an update. Which leads be to believe the transaction operations are being executed in parallel instead of strictly sequentially. This is also supported by the fact that every once in a while it will succeed (parallel operations just happen to be executed in the right order).

2. The other issue is that when these transactions fail, the executed operations are not rolled back. In the example above, I have seen cases where the new foo record exists in the database after the transaction failed on the user.update operation.

No repository file or test is identified in the report. Start by reproducing the Prisma transaction example against ps-http-sim and compare its operation ordering and failure behavior with MySQL. Done means dependent operations run in order and failed transactions leave no partial records.