.NET Framework and Core for Application Development
View All Tags
Authentication to host '127.0.0.1' for user 'inventory_app' using method 'caching_sha2_password' failed with message: Too many connections looks like a login problem, and I went to check the password first. The password was fine. The second half of the message is the real error: MySQL had no connections left to give.
MySQL was restarting, and a statement in the middle of running failed with MySqlException: Server shutdown in progress. That's error 1053, it's temporary, and the server will be back in seconds. The fix is one number in the retry list.
Fatal error encountered during command execution sounds like something is badly wrong with the statement. Read the inner exceptions, and it ends with Attempted to read past the end of the stream: the connection went away while the driver was waiting for an answer. The statement isn't the problem, and it's usually worth trying again.
A statement was stuck behind a row lock, so I stopped it with KILL QUERY. The mysql client reports that as ERROR 1317: Query execution was interrupted. My API got System.NullReferenceException from inside MySql.Data. It's a misleading message, and once you know that, it tells you exactly what happened.
MySQL restarted while orders were coming in. The retries did their job for most requests, and then 8 of 96 failed with System.NullReferenceException from deep inside MySql.Data. None of my code was in the failing frames. A retry was using a connection that the driver had left marked as open.
A request took about 4 seconds, and then failed with RetryLimitExceededException: The maximum number of retries (3) was exceeded while executing database operations. That exception means EF Core did its job and ran out of attempts. The cause is one level down, and the client deserves a better answer than a 500.
An order hung for a while and then failed with MySqlException: Lock wait timeout exceeded; try restarting transaction, and the client got a bare 500. Another transaction held the row. Three things make this better: a shorter wait, a clearer answer for the client, and finding what's holding the row.
Under load, half the orders failed with MySqlException: Deadlock found when trying to get lock; try restarting transaction, and with an HTTP 500. The code looked fine. Each order just locked its products in whatever order the client listed them, so two orders could each hold what the other needed.
Wrapping an endpoint's work in strategy.ExecuteAsync gave error CS8031: Async lambda expression converted to a 'Task' returning delegate cannot return a value. The code looks right, and it returns values on purpose. The compiler just can't work out one type for those values, and a small addition tells it.
As soon as I wrapped two writes in BeginTransactionAsync, the endpoint failed with The configured execution strategy 'MySQLRetryingExecutionStrategy' does not support user-initiated transactions. The message tells you the method to use, and here's the shape of the code it means.
