Installation status #

The publisher’s /connect page connects Cloudflare, selects an account, reserves one installation and starts its native Workflow. Status comes from the authenticated installation registry. Leaving the page does not interrupt execution.

The Workflow persists only a strict progress enum: preparing, deploying, provisioning, verifying, then complete after the existing readiness checks pass. A failed operation retains its last checkpoint. A new operation starts at preparing; older records without a checkpoint remain readable. A ready record is already verified even if it predates checkpoints. This field contains no provider responses, credentials, Workflow event data or customer content.

The browser refreshes the selected installation and a bounded page of owner installations without overlapping requests. Refresh, focus, visibility and restored connectivity reread status; they never start or recover work. A transient read failure retains the last available metadata. Identity-only list responses include the verified ownerSubject to scope an empty list and browser intent; it is not rendered or accepted as browser authority. Deployment authorization expiry does not hide an existing ready installation. Confirmed identity loss clears the visible private state.

Reservation and operation request IDs remain frozen after an ambiguous response. The tab stores only nonsecret owner/account/installation/action identifiers in session storage, so reload and same-owner Cloudflare reconnection can resume the same request. Switching owners discards that context. The saved request is independent of the installation or list page currently being viewed. If another tab changes the server-selected account before reservation, the acknowledged reservation is retained without starting deployment; the owner must explicitly select its account to continue.

Failed installations show a bounded friendly error catalog. Retry targets the existing installation; recovery_required uses the explicit recovery route. Recovery for an apparently interrupted active installation is under an explanatory disclosure because it stops the old attempt before reconciling resources. Polling never invokes it. A verified runtime opens through its exact recorded runtimeOrigin plus /auth/login, using the existing signed owner bridge. Upgrade controls remain a separate concern; a previous release is labeled “Last verified version” if a later operation is not ready.

pnpm test:installation-status runs Chromium against the actual built Octane/Kumo page, real OAuth and installation HTTP routes, native registry/vault Durable Objects and native Workflow. The test substitutes fixed Cloudflare provider/artifact/health boundaries in a fixture entrypoint, uses real TLS browser origins, and checks lost replies, reload, durable progress, explicit recovery, account changes, grant expiry, pagination, offline recovery, owner isolation and 390px layout with 14px content. The independent bridge gate proves the real customer cookie and Sandbox readiness contract. Build the customer release before the control plane; during uncommitted development use pnpm build:control-plane:fixture because the production artifact catalog rejects dirty releases.

Versioned upgrades expose the latest immutable catalog identity, “Up to date,” an explicit Upgrade action and updating recovery. Upgrade intent retains the exact displayed target through ambiguous requests and reloads. During a failed update, “Last verified version” does not promise which code is currently serving; the attempted release can already be active, and the stable Open Flarebot owner-login link remains available.