Elixir Release Handler: Determining Safe Rollback Path After Upgrade Failure

Goal

Recover the node to a stable state after a :release_handler upgrade fails.

Constraints

OTP’s release handler does not provide an automatic rollback. A failed callback leaves the node with a mixture of old and new modules. The decision to purge or keep partially loaded code is unclear, and the semantics of :code.purge vs :code.load_file differ across OTP 26–28.

Unresolved Decision

What is the safest, documented approach to return to the pre‑upgrade code base when an upgrade callback raises an exception?

Specific Questions

1. Should a failed upgrade trigger a full node restart, or can the node purge the offending module and reload the previous version without downtime?
2. How does the presence of :app_upgrade callbacks in OTP 27 influence the rollback path, and can they be leveraged to automate recovery?
3. What are the best practices for preserving state (ETS, Mnesia) during a manual rollback?