Stuck processes on old module version after failed hot code upgrade

Precision Goal

The goal is to understand how Erlang systems should recover from a failed hot code upgrade when some processes remain indefinitely on the old module version. Erlang's hot code loading mechanism keeps both old and new versions active, with processes transitioning only upon fully qualified function calls. This creates a recovery challenge when processes never execute such calls, becoming stuck on the superseded version.

Core Constraint

The unresolved behavior centers on detecting and managing these non-transitioning processes during rollback. The VM does not automatically migrate state between versions, and developers must handle state compatibility. When a failed upgrade occurs, the system needs a reliable mechanism to identify processes still running old code and either force their transition or safely terminate them.

Key Questions

• How can the system reliably detect processes that never perform fully qualified calls and remain stuck on the old version?
• What is the recommended approach for forcing these processes to transition or handling their state during rollback?
• Is there a built-in mechanism to ensure all processes eventually move to the desired version, or must this be handled entirely by application code?