Sintra has two coordinator-side lifecycle surfaces:
set_lifecycle_handler()observes a committed process retirement ascrash,normal_exit, orunpublished.set_recovery_policy()andset_recovery_runner()decide whether and when an opted-in managed-child custody receives its next occurrence.
Crash provenance is carried with the exact managed-child or external-reader generation into the same transaction that removes its publication. The lifecycle callback runs afterward, outside the publication, group, custody, and reader locks. The registry transaction, its unpublish notification, and any delayed publications released by that transaction are enqueued by then. Communication retirement has been requested, but its reader join and custody release can still be completing asynchronously; the callback does not certify either milestone. Recovery is considered only after the lifecycle callback returns.
Recovery belongs to a custody, not to a process instance id. A managed child
calls enable_recovery() once to opt in that custody; its recovery occurrences
inherit the opt-in, while a fresh custody starts disabled even if it reuses the
same id. The coordinator retains the structured launch recipe for that exact
custody. A delayed Recovery_control::spawn() validates the captured custody
and predecessor occurrence again, so it is inert after release, retirement,
shutdown, or id reuse. Externally attached processes have no managed custody
and are never recovered.
The public contracts, threading rules, failure behavior, and examples are in:
sintra::recoverysintra::set_lifecycle_handlersintra::spawn_swarm_processsintra::create_external_process_invitation
Lifeline ownership, collective shutdown, and unilateral departure are separate from these callbacks; see Barriers and shutdown semantics.