@accounter/server
Version:
Accounter GraphQL server
38 lines (37 loc) • 1.99 kB
TypeScript
import { z } from 'zod';
/**
* Zod schema matching the GraphQL `ClientIntegrations` type.
*
* Strict, and exported for a write path that wants to reject an unrecognized
* key outright. Do NOT reach for it to read a value that is already stored —
* see `parseStoredClientIntegrations` for why that direction must not throw.
*/
export declare const ClientIntegrationsSchema: z.ZodObject<{
greenInvoiceId: z.ZodNullable<z.ZodOptional<z.ZodUUID>>;
hiveId: z.ZodNullable<z.ZodOptional<z.ZodString>>;
linearId: z.ZodNullable<z.ZodOptional<z.ZodString>>;
slackChannelKey: z.ZodNullable<z.ZodOptional<z.ZodString>>;
notionId: z.ZodNullable<z.ZodOptional<z.ZodString>>;
workflowyUrl: z.ZodNullable<z.ZodOptional<z.ZodString>>;
}, z.core.$strict>;
export type ClientIntegrations = z.infer<typeof ClientIntegrationsSchema>;
/**
* Parse an `integrations` jsonb value that is already in the database.
*
* Deliberately lenient, because reading and writing have opposite failure costs.
* Rejecting a bad *payload* on a write is the point. Throwing on a bad *stored*
* value takes down far more than the offending row: field resolvers run this
* once per client, and the MCP connector discards partial data whenever a
* response carries any `errors` entry — so a single malformed row would empty an
* entire `allClients` result instead of degrading one record.
*
* Three ways a stored value can be bad, all of which must survive:
* - `NULL` — the column is nullable, and `updateClient`'s COALESCE can land NULL.
* - unknown keys — written by an older deploy, or left behind by a removed field.
* - a wrong-typed value — hand-edited or migrated data.
*
* Every caller already guards the field it wants (`?? null`, or a domain error
* on a missing `greenInvoiceId`), so an unreadable value surfaces as "not
* configured" rather than as a failed request.
*/
export declare function parseStoredClientIntegrations(input: unknown): ClientIntegrations;