error 79 at 1 depth lookup: invalid CA certificate means the certificate you're checking is fine, and the problem is one level up: the CA that signed it isn't marked as a CA. Mine had lost its CA:TRUE because I'd run openssl with no configuration file.

docker compose up printed Recreate when I'd changed nothing, and then root's password stopped working. I had two projects open, and I'd exported one project's .env into my shell. Compose prefers the shell's variables over the .env file, so the other project's container got the wrong values.

not valid in this context is zsh refusing a variable name with a dot in it. ASP.NET Core log categories are full of dots, so to turn one down through an environment variable, export won't do. env will.

Part 3 changed one row at a time. Real work changes several: take the stock, record why, create the order. In this part, those become one unit, you'll watch what MySQL's row locks do when two people buy the last item, and the API learns to survive deadlocks, a MySQL restart and a dropped connection. Some of it surprised me: with Oracle's provider, the retries from Part 1 retry nothing, and a short CommandTimeout can make a request hang for good.

Two people cancel the same order at once. Each one reads Placed, and each one puts the stock back, so you've restocked twice. Put the status in the UPDATE's WHERE, and only one of them can change it. The other one finds out and stops.

A client gives up and closes the connection while your transaction is halfway through. Does the work stop? Is half of it saved? I tried it both ways. The transaction is safe either way, and one case doesn't behave the way the CancellationToken suggests.

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.