@fabrika/provider-zerops 0.8.1 → 0.9.0-dev.2

package/types/src/api/client.d.ts

@@ -0,0 +1,5 @@
+import type { ZeropsApi, ZeropsApiOptions } from './types';
+/** Base URL of the Zerops public REST API. */
+export declare const ZEROPS_API_BASE = "https://api.app-prg1.zerops.io/api/rest/public";
+/** Build the real client. Every request carries the bearer and the run's signal. */
+export declare const createZeropsApi: (options: ZeropsApiOptions) => ZeropsApi;

package/types/src/api/errors.d.ts

@@ -0,0 +1,24 @@
+export declare const isAppVersionNotFoundResponse: (value: unknown) => boolean;
+/**
+ * A non-2xx answer from the Zerops API. `code` is the platform's own error identifier, so a caller can
+ * branch on `userDataDuplicateKey` rather than matching a prose message.
+ */
+export declare class ZeropsApiError extends Error {
+    readonly status: number;
+    readonly code: string;
+    constructor(message: string, status: number, code: string);
+}
+/**
+ * The platform's code for "this service publishes no HTTP port", the answer `enableSubdomainAccess` gives
+ * before a service's first deploy. Exported so a caller can say what is missing instead of relaying prose.
+ */
+export declare const ZEROPS_SERVICE_NOT_HTTP = "serviceStackIsNotHttp";
+/**
+ * Turn a non-2xx response into a `ZeropsApiError`. Zerops answers with `{ error: { code, message, meta } }`
+ * (the envelope observed live; the OpenAPI `Error` schema shows the inner `{ code, message }`).
+ *
+ * `redactDetail` drops the server's MESSAGE, which a validation error can fill with the value it
+ * rejected. The CODE is a fixed identifier and is kept either way — without it nothing downstream can
+ * tell a duplicate key from a missing service.
+ */
+export declare const apiError: (label: string, status: number, body: unknown, redactDetail: boolean) => ZeropsApiError;

package/types/src/api/polling.d.ts

@@ -0,0 +1,41 @@
+import type { Sleeper } from '../collaborators';
+import { type ZeropsApi, type ZeropsProcess } from './types';
+/**
+ * Poll ONE process to completion.
+ *
+ * The same loop `deployPlatformService` (`installation/deploy.ts`) runs over `/app-version`, run over `/process`
+ * instead: read, decide ONLY on a status this build knows to be terminal, sleep, and give up on a deadline
+ * of our own rather than on a coincidence. Returns the finished process so a caller can read
+ * `actionName`/`appVersionId` off it.
+ *
+ * Anything outside `ZEROPS_PROCESS_TERMINAL` means "keep waiting", including a status this build has never
+ * seen — which is why an unpublished vocabulary (see that constant) can cost a timeout and never a false
+ * success. A non-`FINISHED` terminal status throws, naming the status and nothing else.
+ */
+export declare const waitForProcess: (input: {
+    api: Pick<ZeropsApi, "getProcess">;
+    processId: string;
+    sleep: Sleeper;
+    signal: AbortSignal;
+    /** What to call this process in a failure or timeout message. Defaults to its id. */
+    label?: string;
+    intervalMs?: number;
+    attempts?: number;
+}) => Promise<ZeropsProcess>;
+/**
+ * `enableSubdomainAccess`, repeated while the service does not yet publish an HTTP port.
+ *
+ * Live-verified: right after a service's first app version reads ACTIVE the platform still answers
+ * `serviceStackIsNotHttp`, and a minute later the same call is accepted. The ports lag ACTIVE, so that
+ * answer means "not yet" for a bounded window. Past it the last refusal is rethrown unchanged, so a caller
+ * still names the missing port. Any other failure is rethrown at once. The 2xx still proves nothing: the
+ * caller decides by reading `subdomainAccess` back.
+ */
+export declare const enableSubdomainAccessWhenHttp: (input: {
+    api: Pick<ZeropsApi, "enableSubdomainAccess">;
+    serviceId: string;
+    sleep: Sleeper;
+    signal: AbortSignal;
+    intervalMs?: number;
+    attempts?: number;
+}) => Promise<void>;