Don't abort connection in mysql after encoding error #535
Conversation
why waste time say lot word when few word do trick
Right now it just replaces the `firstPacket` variable with a separate state. But in the future it can be extended to support other states to model a state machine if needed.
[skip ci]
I tested the normal workflow. like this: Where But I also wanted to test this workflow: Where encoding error happens before some |
yes. I think it should be some transaction that fails on commit. and there is should be Parse("BEGIN") + Execute + Parse("insert ...") + Execute + Parse("COMMIT") in same TCP packet. Then database probably will return responses one by one or it will fail on their side and return only error ))) |
This PR implements flushing of db-packets till the end of response after the encoding error. This is done to clear the connection so it can be reused for other queries (like
rollbackfor example).This also adds a couple of tests that show the correctness of the execution. I also wanted to add test with query which produces mysql error after a couple of data packets, so we can check that acra throws "encoding error" earlier and eats the mysql one. But I just couldn't craft such query ._.
Mysql returns
nullin almost every error case (division by zero, unable to allocateREPEAT('A', 1TB), etc). In cases where I could trigger a runtime error it is not possible to use acra, because query is complex. Maybe you can come up with an idea?Checklist
with new changes
CHANGELOG.md is updated (in case of notable or breaking changes)Benchmark results are attached (if applicable)Example projects and code samples are up-to-date (in case of API changes)