.NET Framework and Core for Application Development
View All Tags
A row lock lasts until the transaction ends, not until the statement ends. So a payment call, an email or a file upload inside a transaction keeps that row locked the whole time, and everyone who wants it waits. I measured it: moving one slow call out took another request from 2.5 seconds to 0.013.
A connection that drops just after MySQL commits and just before your app hears about it is rare, which means your retry code probably hasn't met it. You can make it happen on demand with a small proxy, then see for yourself whether a retry repeats the work. Everything here is for your own machine.
A race condition doesn't show up when you send one request at a time. You need several at the same moment, and you don't need a load-testing tool: curl with xargs does it on macOS and Linux, and ForEach-Object -Parallel does it in PowerShell. Then check what's in the database, because the status codes alone can look fine.
Attributes check one value at a time. When a rule involves more than that, such as "no product twice in one order", or "this number can be anything except 0", put it on the request itself with IValidatableObject. AddValidation calls it, and the error comes back in the same format as the others.
An order has a list of lines, and two things can be wrong with it: the list itself, and any one of its items. AddValidation in .NET 10 checks both, and it tells the client exactly which item is wrong.
By default, an enum in a minimal API's JSON is a number, and "type": 0 tells a reader nothing. One line in Program.cs makes every endpoint use the names, in both directions. It's worth knowing exactly what it accepts on the way in, too.
An IExceptionHandler is one class that decides what clients see when an exception escapes an endpoint. It answers the ones it recognises, and leaves everything else alone. Here's a complete one, and the setting I add since .NET 10.
When MySQL is down, or a row is locked for too long, a 500 tells the client that your code has a bug and there's no point trying again. 503 Service Unavailable with Retry-After says the truth: not now, come back in a few seconds. An exception handler does it in one place, for the whole API.
To read a request header in a minimal API, add a parameter with [FromHeader]. One detail decides how it behaves: string? makes the header optional, and string makes it required, with a 400 if it's missing.
A client that gets no answer can't tell whether its POST worked. If it tries again, you can get two orders. An Idempotency-Key header fixes that: the client sends the same key each time, and the second request gets back what the first one made.
