Function resync_controller 

pub fn resync_controller(
    block: &Block,
    tab_id: &str,
    rt_opts: Option<Value>,
    force: bool,
    respawn_if_done: bool,
    broker: Option<Arc<Broker>>,
    event_bus: Option<Arc<EventBus>>,
    mstore: Option<Arc<Store>>,
    filestore: Option<Arc<FileStore>>,
    id_store: Option<Arc<Store>>,
    identity_store: Option<Arc<Store>>,
    registry: Option<Arc<Registry>>,
    boot_id: Arc<str>,
    auth_key: &str,
    config: Option<Arc<ConfigState>>,
) -> Result<(), String>

Resync a block’s controller — the main entry point for starting/restarting blocks. Port of Go’s ResyncController.

Logic, for the block passed in:

1. Determine controller type from meta[“controller”]
2. If the existing controller needs replacing (type changed, conn changed, force), stop it
3. Create a new controller if needed
4. Start it if status is init, or done when respawn_if_done allows (below)

respawn_if_done: when the existing controller’s status is STATUS_DONE (its process already exited), should this call revive it via ctrl.start() (the historical, unconditional behavior — pass true), or leave it dead and return Err(RESYNC_ERR_ALREADY_EXITED) instead (pass false)? true is correct for crash/backend-restart recovery (the WS ControllerResyncCommand path, TermResyncHandler — see its own doc comment for why a dead PTY must come back transparently there). false is for a caller that needs to tell “this exited on purpose” apart from “this needs reviving” using the SAME status read resync_controller itself makes, rather than checking status in the caller first and racing a StatusDone transition landing between that check and this call — try_attach_to_existing_shell (server/mod.rs, PtyShellCreate’s pane-shell-reuse path) is the one caller that needs this; see docs/specs/SPEC_TERM_EXIT_RESPAWN_LOOP_2026_09_15.md §7.