In case of SBR/MBR, if a query executed on master has already modified something that cannot be rolled back, and it gets interrupted in the middle, it is written to the binlog with the corresponding error code.
When slave reaches it, replication aborts with
Query partially completed on the master (error on master: 1317) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query ...
This happens on maria/5.5 revno 3458, and of course before it too, as well as on MySQL 5.5/5.6. (5.1-based versions too, but it obviously makes no sense to touch them).
In case of SBR it is probably unavoidable. But if MBR is used, it could make sense to log such changes in row mode, which works perfectly fine (only updated rows are written, no error code is needed, replication goes as usual).
(if you have a super-fast machine, and reap succeeds instead of throwing ER_QUERY_INTERRUPTED, you might want to insert more records into t1):