I had read that MULTI/EXEC would not "rollback" incase a command fails (e.g. you do first SET, second SET, third SET fails, then the two initial SETs would still be applied). I guess this doesn't so much have to do specifically with persistance problems (system crash, process crash, etc..) but more with just how transactions work in general.
redis> multi
OK
redis> set hi 'hello'
QUEUED
redis> rpop hi
QUEUED
redis> set okay 'done'
QUEUED
redis> exec
1. OK
2. (error) ERR Operation against a key holding the wrong kind of value
3. OK
redis> get okay
"'done'"
redis> get hi
"'hello'"
redis>
Note that it keeps on processing, even though the second command fails. This also has nothing to do with persistence, as the exhibited behavior will be the same in a fully-alive system and from disk and anything else, because redis maintains a perfect total ordering of operations in its log format and sync behavior.
Maybe SET wasnt a good example .. but lets say you are writing to the wrong type or something like that. I know that its unlikely something will fail in production like that since you should catch it during dev but bugs can happen.
Is this not true or at least no longer true?