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 stable publisher entry mounts its own PublisherQueryProvider, separate from the customer runtime. Every read has a reusable hook under control-plane/ui/queries/: identity bootstrap, connection, installation list/detail, domain detail/zones and provider detail. An identity-only installation response (or a successful connection check) establishes a verified owner and seeds its scoped cache; the bootstrap query does not retain private installation metadata. Resource keys include owner and session generation, plus cursor, installation and account where those inputs affect the result. No query cache is persisted or included in public SSR.

Query refreshes the selected installation and a bounded page of owner installations without overlapping requests for a resource. Installation status polls every 2 seconds while active and 30 seconds otherwise; update progress polls every 1.5 seconds, and domain transitions every 3 seconds. Hidden pages stop polling. 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 or change cancels the previous owner’s queries, clears private cache and command editors, and removes their saved intents. Connection, domain and provider responses also carry the server-verified owner so a reply from a changed session cannot enter the previous owner’s cache.

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.

The installation controller retains only selection, frozen command intents, pending state and command errors. Saved installation data comes directly from Query. Installation reads retain their 15-second deadline; installation commands allow 120 seconds for acknowledgement, including response-body consumption. Domain and provider commands keep their existing deadlines and explicit retry behavior. Update-on-visit uses a separate one-shot controller: query functions only GET status, and focus, polling or reconnect cannot repeat an upgrade POST. Its submitted flag and frozen release target survive reload for status reconciliation and manual recovery.

Pagination commits the displayed cursor only after the requested page loads into Query. Failed page requests retain the current rows and navigation controls for explicit retry. The newly loaded page uses the normal 30-second freshness window, avoiding a duplicate read when its observer mounts; focus and the existing polling intervals still refresh status.