import { BaseSubgraph } from "@powerhousedao/reactor-api";
import type { DocumentNode } from "graphql";
export declare class VetraCloudObservabilitySubgraph extends BaseSubgraph {
    name: string;
    typeDefs: DocumentNode;
    resolvers: Record<string, unknown>;
    additionalContextFields: {};
    private watcherHandle;
    private deploymentReconciler;
    private ownerBackfill;
    private protectionReconciler;
    private challengeReconciler;
    private releaseIndexBackfill;
    private clintPullWorker;
    private dumpJobWatcher;
    private dumpRowPruner;
    private dumpsK8s;
    private dumpsRepo;
    private dumpsS3;
    onSetup(): Promise<void>;
    onDisconnect(): Promise<void>;
    /**
     * Build the dump-feature dependencies. Returns null when S3
     * credentials aren't configured so the rest of the subgraph still
     * boots — the dump query/mutation simply aren't registered.
     */
    private buildDumpDeps;
    /**
     * Periodically reconciles in-flight dump rows against their k8s
     * Jobs. List the cluster's managed Jobs once per tick and look up
     * each in-flight row by its dump-id label, so subgraph restarts
     * resume cleanly.
     */
    private startDumpJobWatcher;
    /** Hourly sweep that drops dump rows older than 7 days. The S3 file
     *  itself expires at 24h via bucket lifecycle; we keep the row
     *  visible for a week so users see "expired" history rather than
     *  silently disappearing dumps. */
    private startDumpRowPruner;
    /** Grace period (ms) before marking a DEPLOYING environment as failed.
     *  Services like switchboard need time for image pulls, migrations, and
     *  health-probe warm-up — ArgoCD will report DEGRADED during this window. */
    private static DEPLOYMENT_GRACE_MS;
    /**
     * Periodically checks for environments in CHANGES_PUSHED/DEPLOYING status
     * and transitions them to READY/FAILED based on ArgoCD state.
     *
     * Queries the processor's environments table (via a shared DB namespace)
     * and the observability environment_status table.
     */
    private startDeploymentReconciler;
    /**
     * Seeds state.owner on historical environments by dispatching a system-signed
     * SET_OWNER action with the address from the processor's createdBy column.
     *
     * Why this works without forging signatures:
     *   The SET_OWNER reducer allows system-signed actions (no user in the signer)
     *   to set any address when state.owner is null. User-signed claims are still
     *   restricted to the signer's own address.
     *
     * Idempotent — skips rows where owner is already set or createdBy is null.
     * Runs on startup and every 5 minutes as a safety net in case a dispatch
     * failed (e.g., document was locked).
     */
    private startOwnerBackfill;
    /**
     * Enforces document-level read protection at the reactor-api layer for every
     * env that has an owner. Idempotent:
     *   - Queries envs with owner set.
     *   - For each, reads the document's protection record.
     *   - If it isn't already { protected: true, ownerAddress: owner }, calls
     *     initializeDocumentProtection(docId, owner, true) — which sets
     *     protection + owner + grants the owner ADMIN in one shot.
     *
     * AuthorizationService behaviour after this:
     *   - supreme admins (ADMINS env) → can read/write (unchanged)
     *   - owner → can read/write (implicit ADMIN)
     *   - anyone else → 403 on getDocument / findDocuments / mutations
     *
     * Unowned envs are left alone — they stay "public" per the reducer contract.
     *
     * Runs every 60 seconds: short enough that the window between a new env
     * being claimed and being protected is acceptable, long enough to not
     * hammer the DB. The alternative (hooking the reactor's operation stream)
     * would be tighter but requires more plumbing.
     */
    private startProtectionReconciler;
    private dispatchAction;
    /**
     * Rescues cert-manager certs whose HTTP-01 Challenge lost the first-provision
     * race against external-dns. The flow is:
     *
     *   1. list every Challenge cluster-wide whose `status.state == "invalid"`
     *      AND whose reason mentions NXDOMAIN (the specific race we solve here,
     *      not e.g. webhook failures or network errors)
     *   2. for each, resolve4 the challenge's dnsName; if it now returns one of
     *      the cluster's LB IPs, DNS has caught up
     *   3. throttle via the `vetra.io/last-retry` annotation on the owning
     *      Certificate — skip if we already retried within LAST_RETRY_COOLDOWN
     *   4. delete the Certificate; cert-manager's Ingress-shim re-creates it
     *      on the next reconcile with a fresh Order, which now passes the
     *      HTTP-01 challenge
     *
     * With DNS-01 enabled for *.vetra.io this path shouldn't fire for our own
     * tenants; it exists for external customer domains that stay on HTTP-01.
     */
    private static CLUSTER_LB_IPS;
    private static LAST_RETRY_COOLDOWN_MS;
    private static LAST_RETRY_ANNOTATION;
    private startChallengeReconciler;
    /**
     * Periodically populate `release_index` from npm dist-tags on
     * `@powerhousedao/connect` and `@powerhousedao/switchboard`. The
     * monorepo publishes every release to npm with dist-tags `dev`,
     * `staging`, and `latest`, each pointing at the current channel head.
     *
     * Without this, `release_index` only has rows for channels whose
     * webhook has fired since the subgraph started — so a new staging
     * env subscriber sees "no release seen" in the UI even though a tag
     * exists on npm. With this, the UI's "latest on channel" and the
     * updateEnvironmentToLatest mutation work immediately, and the
     * notifyNewImageRelease webhook still keeps things fresh on new
     * releases (first writer wins, later writers no-op).
     */
    private static RELEASE_INDEX_PACKAGES;
    private static RELEASE_INDEX_CHANNELS;
    private startReleaseIndexBackfill;
}
//# sourceMappingURL=index.d.ts.map