Unexpected behaviour with InnoDB Transaction retry
When the deadlock occurs at query 3, the deadlock may involve query 1 or 2.  You must start over with the START TRANSACTION and replay all the queries.
If any of those are SELECTs and the result of the SELECT controls what will be subsequently UPDATEd, DELETEd, etc, then do you have FOR UPDATE on the SELECT?
You must check for errors after each and every query in the transaction.  If a deadlock occurs, start over, as mentioned above.
What happened

The error occurred, so it rolled back the transaction as far as it had gone.
The client code ignored the error and plowed ahead.
Queries 4,5,6 were run and committed.

What was needed

The error occurred, so it rolled back the transaction as far as it had gone.
The client code noticed the error.
The client code should have code to ROLLBACK and jump back to the START.

(The explicit ROLLBACK is probably redundant but harmless.  However, branching back to the START is up to the client code.)
A &quot;deadlock&quot; should be handled that way, but any other &quot;error&quot; should be handled with an abort.
And, since a deadlock can occur after virtually any query, you should test everywhere.