Limits of Vert.x Verticle State Migration During Rollback

Limits of Vert.x Verticle State Migration During Rollback

Goal: Determine whether Vert.x offers a built‑in mechanism to transfer in‑memory verticle state (such as fields, caches, or timers) from a failed version back to a previously known‑good version during a rollback triggered by a health‑check failure.

Constraints: Vert.x allows undeploying a verticle and redeploying a previous version using the DeploymentID returned by deployVerticle, and the Health Check API can report DOWN to initiate that redeploy. However, the documentation notes that in‑memory state is lost on undeploy and provides no automatic state‑migration facility.

Uncertainty: It remains unclear what patterns Vert.x developers should adopt to persist state across versions, whether any lifecycle hooks exist to serialize state before undeploy, and what trade‑offs arise when using external stores for this purpose.

What are the recommended approaches for persisting verticle state to enable safe rollback?
Does Vert.x expose any pre‑undeploy callbacks that can be used to save state?
Are there any known limitations or risks when relying on external storage for state migration in a Vert.x verticle?