Faux idempotency — Paperless

Writing idempotent code is great. It should always result in the same final state, so it’s easy to test. And a failed run shouldn’t affect the next one, making it reliable and safe. But as you’ve noticed I used “should” in both places, because code which looks idempotent may not be.

This article was inspired by How to write idempotent Bash scripts by Fatih Arslan. It is not at all my intention to dunk on that article in particular — there are lots of good tips in there — but rather to illustrate that actual idempotency is harder to achieve than the article purports, and we should be careful not to declare some code idempotent when it isn’t.

The first example of idempotent-but-not-really code in the article is touch example.txt. The author takes care to mention one way this is not idempotent: it updates the file’s modification time. But there is a more subtle way this is not idempotent, because it depends on state which you are generally not in complete control over. For example, if someone changes the access rights of the file so that you no longer have access to modify it, touch will fail:

The obvious objection to this is that of course the root user could sabotage your process, because it has full system access. But the same would happen if the filesystem is mounted read-only between the first and the second touch, which can happen automatically, for example if the system detects any issues with the storage medium.

Leave a Comment