GET /orders?status=99 didn't fail. My enum has three members, and the endpoint happily ran with status 99, which then filters to nothing, with no sign that the request was wrong. .NET's enum parsing allows this on purpose, so the check is yours to add.
?status=Placed worked, and ?status=placed gave a 400 Bad Request with no explanation. The reason was only in the log: Failed to bind parameter "Nullable<OrderStatus> status" from "placed". JSON bodies accept any case here, and query strings don't.
A request that listed the same product twice in one order got a 500, and the log had MySQL's Duplicate entry '2-9' for key 'order_lines.IX_order_lines_OrderId_ProductId'. The database was right to refuse. But a mistake in the request should be a 400, and it shouldn't take stock and open a transaction to find out.
Under load, sales failed with MySqlException: Check constraint 'CK_products_QuantityOnHand' is violated. and an HTTP 500. The stock never went below zero, so the constraint had worked. The problem is that a buyer who should have heard "out of stock" heard "server error".
The response said "type": 0. The database row said Receipt, because I'd configured EF Core to store enums as strings. Nobody reading the API would know that 0 means a receipt, and adding a value in the middle of the enum would quietly change what every number means.
My IExceptionHandler turned database errors into a 503, and the client got exactly what it should. Then I looked at the log for the error it had handled, and the middleware's line wasn't there. That's a change in .NET 10, and one option brings the line back.
My log said Connection must be valid and open to rollback transaction, and that wasn't what had gone wrong. Something had failed after the commit, my catch tried to roll back a transaction that was already finished, and the new exception replaced the real one. The fix also removes code: you rarely need RollbackAsync at all.
Connection must be valid and open to commit transaction sent me to look at the connection, and the connection was fine. The transaction had already been committed. A second CommitAsync on it found the connection closed, and that's the only thing the driver checks first.
Calling one helper method from inside a transaction failed with The connection is already in a transaction and cannot participate in another transaction. The helper had its own BeginTransactionAsync, which made sense when it was written, and it stopped making sense once something else called it inside a transaction.
I had a Version concurrency token on products, so I tried it against overselling. It worked, and it also turned away customers: with 100 in stock and 5 simultaneous orders, 3 got 409 Conflict. They weren't conflicting over stock at all. They'd just happened to read the same version.
