# Failed generation recovery When a Rollbridge activation fails or its client times out before publication, Rollbridge retains an exact generation-transition fence. The candidate may still be alive while the incumbent remains the authoritative web release. Use Rampway's guarded recovery command after the original deploy command has exited: ```bash rampway production runtime-recover-generation-transition --yes ``` The command holds Rampway's deploy lock and resolves both the retained failed release and the unchanged `current` release. It verifies their `REVISION` and `TRESTLE_RELEASE.json` identities, checks that `current` matches Rampway's stable runtime state, prepares and verifies the candidate's immutable Rollbridge snapshot, and requires Rollbridge's live transition to match the same candidate and incumbent before recovery. A stage without an explicit `runtime.config` verifies its config-less forward-deploy contract without inventing immutable config material; rollback and foreground boot continue to require the stronger retained-config contract. Before invoking recovery, Rampway conservatively pins the verified candidate so an interruption or invalid post-recovery response cannot make its draining processes cleanup-eligible. Successful recovery retires only the failed candidate and leaves the incumbent authoritative. The command then verifies that Rollbridge cleared the transition, that the incumbent is the sole active release, and that the candidate is absent, draining, or stopped. Rampway preserves the current symlink and accepted runtime state while reconciling the verified references as pins owned by the candidate's exact runtime configuration, excluding the current incumbent that is already protected by `current` and accepted state. An authoritative incumbent refresh therefore cannot clear a draining candidate's pins, while a later deployment can clean the former incumbent normally. The same owner-scoped protection and incumbent exclusion apply when Rollbridge performs automatic recovery during deploy or rollback. Rampway persists those automatic-recovery pins before releasing the deploy lock. Every later successful Rollbridge deploy or rollback refreshes live owner pins before publishing `current`, so a status-refresh failure leaves the previously accepted release and state authoritative. A repeat for the same retained candidate is safe and reports `already_recovered`. This command deliberately does not deploy a release, publish `current`, run deployment hooks, clean releases, or change the accepted runtime snapshot. Identity or phase mismatches fail closed; investigate them instead of using the generic `runtime-recover` command as a substitute.