Fixes for Common Issues and Errors
View All Tags
int.Parse on a number from configuration stopped the build with error CA1305: The behavior of 'int.Parse(string)' could vary based on the current user's locale settings. The analyzer has a point, and the fix is one argument, once you decide whose culture the text is in.
Asking for IsolationLevel.Snapshot failed with NotSupportedException: Snapshot isolation level is not supported. Coming from SQL Server, that sounds like MySQL can't do it. It can: MySQL's default level already reads from a snapshot, under a different name.
SELECT VERSION() is about the simplest query there is, and db.Database.SqlQuery<string>(...).FirstAsync() failed with Unknown column 's.Value' in 'field list'. My SQL has no s and no Value. EF Core added both, and it expects one thing from you.
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.
