/** * `SourceAdapterRegistry` — process-local map keyed by `connection_id` that * the booking engine and channel-push pipeline consult when dispatching a * quote / book / cancel / push call. * * Templates wire the registry at process start, registering one adapter * instance per upstream connection. Two connections of the same kind * (e.g. TUI dev + TUI prod, or two different Voyant Connect peers) get * two registry entries with two distinct `connection_id`s — different * credentials, different rate buckets, different `channel_id` mappings. * * `kind` remains a useful secondary index — "list all adapters of this * kind" supports rotate-to-next-available policies and admin debug * surfaces. But routing dispatches by `connection_id` because that's * what the data carries (provenance.source_connection_id on sourced * rows, channels.id on outbound mappings). * * Per channel-push-architecture §3.1 and catalog-booking-engine §4. */ import type { SourceAdapter } from "../adapter/contract.js"; /** * One registry entry. `connectionId` is the typed-id key (the row in * whichever table holds the connection record — `channels` for outbound, * the catalog plane's connection store for inbound). For adapters with * no upstream connection record (e.g. the demo adapter at boot), pass a * stable synthetic id like `"default:"`. */ export interface RegisteredAdapter { connectionId: string; adapter: SourceAdapter; } export interface SourceAdapterRegistry { /** * Register an adapter under a connection id. The connection id is the * primary key — re-registering the same connection id replaces the * previous adapter (used at hot-reload time). Production registrations * happen once at process start, one entry per upstream connection. */ register(connectionId: string, adapter: SourceAdapter): void; /** * Backward-compat overload — register an adapter without an explicit * connection id. Stored under the synthetic id `"default:"`. * Use this for single-deployment adapters where there's no separate * connection record (e.g. demo adapters, single-tenant integrations). * New code paths that route per-connection should prefer the explicit * `register(connectionId, adapter)` form. */ register(adapter: SourceAdapter): void; /** * Resolve by connection id. Hot path for the booking engine (sourced * bookings) and the channel-push pipeline (outbound dispatches). * Returns `undefined` when no adapter is registered. */ resolveByConnection(connectionId: string): SourceAdapter | undefined; /** Like `resolveByConnection` but throws `NoAdapterRegisteredError` on miss. */ resolveByConnectionOrThrow(connectionId: string): SourceAdapter; /** * Resolve by source kind. Returns the FIRST adapter registered for this * kind. Useful for legacy dispatch paths that don't yet thread a * connection id, and for the common single-connection-per-kind case. * New code that supports multiple connections per kind should use * `byKind` to pick deliberately. */ resolveOrThrow(sourceKind: string): SourceAdapter; /** * Returns every adapter registered for this kind, paired with its * connection id. Order is registration order. Use for "rotate to next * available connection" policies and admin debug surfaces. */ byKind(sourceKind: string): ReadonlyArray; /** Returns the registered connection ids. */ connections(): ReadonlyArray; /** Returns the registered source kinds. */ kinds(): ReadonlyArray; /** True iff a connection id is registered. */ has(connectionId: string): boolean; /** True iff at least one adapter of this kind is registered. */ hasKind(sourceKind: string): boolean; } /** * Construct a fresh registry. Templates create one at process start and * pass it to the booking-engine route handlers + channel-push wiring. */ export declare function createSourceAdapterRegistry(): SourceAdapterRegistry; //# sourceMappingURL=registry.d.ts.map