.NET Framework and Core for Application Development
View All Tags
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.
One unit left, five simultaneous orders, and all five answered 201 Created. The order code was in a transaction, and it checked the stock first. It looked correct, and the first time I ran it, it even behaved. The check and the write were two separate steps, and every order did the check before any of them had written.
One request answered 201, and the database had two orders, with the stock taken twice. MySQL had committed the first attempt, the connection dropped before the reply arrived, and EF Core's retry, knowing only that the commit had failed, did it all again. Retrying is only safe when each attempt can tell that an earlier one already worked.
The connection dropped during a transaction, EF Core retried it as it should, and the request created two rows, with different names, from one request. MySQL had rolled the first attempt back. The extra row came from my DbContext, which still remembered the first attempt's entity.
