Ktor Upgrade Rollback: No Built‑in Recovery

Problem Context

Ktor provides a graceful shutdown via Application.stop(), but once an upgraded JAR or configuration fails to start, the framework offers no automatic rollback. Deployments must rely on external orchestrators or manual intervention to restore the previous working artifact.

Constraints & Uncertainty

• The configuration schema (application.conf) evolves across releases; missing or incompatible settings can cause start‑up failures.
• Ktor’s client and server libraries lack version pinning, so mismatched dependencies can trigger runtime protocol errors that are hard to diagnose.
• In production, rolling upgrades typically use Kubernetes or Docker Swarm readiness probes, but the orchestration layer does not coordinate a fallback to the previous pod if the new one never becomes ready.

Open Decision

There is no documented automatic rollback mechanism in Ktor. The community has not agreed whether to implement one internally or to rely entirely on external orchestration. Developers must decide how to handle upgrade failures: manual rollback, custom scripts, or awaiting a future Ktor feature.

Questions

1. Which approach—external orchestrator readiness probes, custom pre‑stop hooks, or a proposed Ktor plugin—would best support automatic rollback on upgrade failure?
2. Can Ktor be extended to detect a failed start and trigger a rollback to the previous artifact without external tooling?