Haha, no worries.
We actually elected in v3 not to do an automatic rollback, because many people found it inconvenient to debug, and we're essentially defaulting to deleting stuff in production.
There was many weird edge cases with assets being incorrecly removed, etc, etc, et... nothing that was 100% our fault, but we figured just failing clearly was a better way to handle that.
In your own code, you can rescue it, and Rake::Task["deploy:rollback"].invoke, but it's probably wiser in this case (and, in my cases, usually) to do a switch on the shell, decide what to do, and then rollback.
Of course a rollback is weird, because we have to delete the folder in order to keep the "newest release" logic working, but often if you had a bad deploy, you need the contents of that folder to do some forensics.
For that reason, keep doing what you are doing, and consider adding a task to copy the broken release to a safe place, before it's removed by it is removed
in the rollback flow.
If for some reason cap is failing, but you get a zero-exit status, then let me know specifically what's going wrong, and I'll fix that, you should be able to rely on our exit statuses being informative.