RecoverySupport

Subscriby\Connector\Contracts\Ports\RecoverySupport. Bound by any recovery_* capability.

The Disaster Recovery Program is one core subsystem (incidents, an operations ledger with undo, readiness, quotas, member notices) with five platform facets the manifest's recovery block switches on. The core never calls a facet the block denies; a connector implements the denied ones by throwing UnsupportedByConnector.

Methods

Vocabulary and readiness

RecoveryVocabulary names the connector's world: installationNoun ("bot"), spaceNoun ("channel"), identityNoun ("Telegram account"), grantNoun ("invite link"), the plurals installationsNoun and spacesNoun, and optional sentences the pages use verbatim (mirrorNote, installationHandoverNote, installationMovedAnnouncement). Every noun must be non-empty. A creator with two connectors installed sees two recovery cards saying different things, in the right words each.

readinessChecks() returns the connector's lines of the checklist as ReadinessItems: a unique key, label, description, icon, satisfied, prevention (whether the item belongs to the paid prevention tier), fixRoute (a named route the fix button opens) and detail. Read the facts from Core\Recovery::coverage($project, $connector), which answers a RecoveryCoverage: whether a standby installation exists, whether failover is automatic, and one SpaceCoverage per gated place (hasStandby, standbyHealthy, mirrored). The core's own three checks (a second factor, a second administrator, an off-platform copy) are added by the core.

healthReasonText($code) lets the connector replace the core's generic sentence for a health reason code with its own label and explanation ("recreate the bot in @BotFather"); return null for a code you have nothing to add to.

The probes

Three probes, because the core acts differently on each:

• probeInstallation() answers an InstallationHealth like InstallationLifecycle::verify(); use the same platform call so the two never disagree.
• probeSpace() answers a SpaceAccess: ready, a state word, a detail sentence and creatorActionable. The core writes it to the place's health and shows the connector's remedy.
• probeIdentity() answers null while the account still answers, a TargetMissing failure when the account is gone (the incident the program exists for), and any other kind when the account exists but cannot be reached or the platform could not be asked, which the core leaves alone.

Standby installations

registerStandbyInstallation() proves the standby with the platform and stores your own row for it, but registers it for nothing: it receives no events and answers nobody until a failover writes it into the live installation's place. Answer an InstallationSummary whose storageRef names your row; the core records the neutral installation row (role standby) from it. Throw InstallationRefused when another installation already holds the credentials or the platform refuses them. removeStandbyInstallation() forgets it; nothing was ever registered on the platform, so nothing is withdrawn.

Failover and mirroring

failOver() moves every holder from a lost place to its standby: the holders are GrantSnapshots (grant, space, identity, state) for everyone who should be in the standby; answer a FailOverReport (readmitted, failed, failures). mirror() copies one post by its platform id into the standby and answers a DeliveryResult. Both need a resource kind marked mirrorable for the mirror to be offered.

Identity relink

beginIdentityHandshake() starts proving that a creator controls an account, for a relink after a ban or a backup identity registered in advance: like PortalLoginMethod::begin(), it answers a PortalLoginStart for the platform-scope installation, and the connector's inbound side completes the handshake with Core\Identities::completeHandshake().

How Telegram does it

A bot is probed with getMe, the same call that verifies an installation; a chat with getChatMember on the bot's own id, the one call that tells a deleted chat from a removed bot from a missing right; an account with getChat on its private chat, which is side-effect free and is how Telegram says user is deactivated. The standby bot is proven with getMe and kept in the connector's own table until a failover.

What the kit checks

recovery.vocabulary_and_readiness: every noun of the vocabulary is non-empty, and readinessChecks() returns ReadinessItems with unique keys for a synthetic installation and project.