.NET Framework and Core for Application Development
View All Tags
The provided key is invalid sounds like a problem with a key file of yours. It isn't. The server's certificate was signed by a different CA that has the same name as the one in your SslCa file, and MySQL's automatic CAs all have the same name.
The certificate authority (CA) does not match means the check worked: the server's certificate wasn't signed by the CA in your SslCa file. But it caught me a second time when the right CA was in the file, because MySql.Data reads only the first certificate in it.
The key was good, and MySQL had made it itself, yet the driver said The specified file cannot be converted to a key. It isn't the key, it's the wrapping: MySql.Data reads only one of the two formats that OpenSSL writes, and it isn't the one you get today by default.
SslMode=VerifyCA worked. Moving up to VerifyFull, which only adds a check of the server's name, failed with a complaint about a client certificate I'd never needed. The driver insists on one with PEM files, and then it never sends it.
I raised SslMode from Required to VerifyCA and the connection stopped working, with No file path has been provided for the connection option SslCa. VerifyCA means "check who signed the server's certificate", so the driver needs to know which signature to trust, and it only looks in the file you give it.
No error page and no 500: the whole API process ended, in the middle of a burst of requests. The message mentions authentication and I/O, and neither was the problem. The real cause is more requests at once than Maximum Pool Size, and a callback inside the driver that throws where nothing can catch it.
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.
