Yes, you are right on your assessment of putting it on the wrong event. When an event occurs, the actions you specify will run. Once the transaction is completed, you might send out emails, or HTTPS POST data to another system, but it's definitely odd to set an auto-cancel timestamp.
It never hurts to look at a transaction's activity log to see what happened and in what order.
If you look at your transaction listing, you will see what the status of each transaction is. If it were canceled, the status would say this exactly. Your transactions show the status of completed. Even though you set an auto-cancel date in the future, because the transaction is completed, nothing will happen.
A transaction can only be auto-canceled if the date has been reached AND the transaction is still in progress.
For you, you want to set the auto-cancel when the transaction is started, not completed. Doesn't that make sense? When the transaction starts, you want to set an auto-cancel timestamp so that if they don't complete it by that date, it will cancel itself. Often you may even delete the transaction earlier than the standard retention for this scenario. For multi-party transactions, you would more typically set the cancel timestamp on transaction start, and then cancel the auto-cancel when the first party completes the first document or completes them all.