// ---------------------------------------------------------------------------// Cloud execution-stack seams.//// The shared `makeExecutionStack` (@executor-js/api/server) owns the body://   makeScopedExecutor -> createExecutionEngine -> EngineDecorator.decorate.// Used by the protected HTTP API (per-request) and the MCP session DO// (per-session) so changes to the stack flow to both. Cloud supplies the five// seam Layers it reads from; the only cloud-specific differences are the// Cloudflare dynamic-worker code substrate and the usage-metering decorator.////   - DbProvider          -> cloudDbProviderLayer: rebuilds the postgres-js fuma//                            client per request off the request-scoped//                            `DbService.db` (Hyperdrive forbids sharing an I/O//                            handle across requests). The shared factory reads//                            `db` without caching, preserving per-request rebuild.//   - PluginsProvider      -> fresh per-request plugins with the Worker env's//                            WorkOS credentials.//   - HostConfig           -> `allowLocalNetwork` is config-driven (the//                            `ALLOW_LOCAL_NETWORK` var; production leaves it unset//                            -> `false`, the test workers set it `"true"`). It is//                            an SSRF/private-network guard, so it MUST NOT key off//                            a test flag. `webBaseUrl` is `VITE_PUBLIC_SITE_URL ??//                            executor.sh`.//   - CodeExecutorProvider -> `makeDynamicWorkerExecutor({ loader: env.LOADER })`.//   - EngineDecorator      -> the billing decorator that meters each execution//                            to Autumn. BOTH cloud execution planes (the HTTP//                            `/api/*` executor plane AND the MCP session DO) use//                            the metered stack (`CloudMeteredExecutionStackLayer`,//                            ../engine/execution-stack-metered.ts), since the MCP//                            server is the primary execution surface. Billing//                            still lives in the cloud app, not this neutral//                            seams module; the decorator is composed on top.// --------------------------------------------------------------------------- import { env } from "cloudflare:workers";import { Layer } from "effect"; import {  CodeExecutorProvider,  DbProvider,  HostConfig,  PluginsProvider,  collectTables,  type HostConfigShape,} from "@executor-js/api/server";import { makeDynamicWorkerExecutor } from "@executor-js/runtime-dynamic-worker";import type { AnyPlugin } from "@executor-js/sdk"; import executorConfig from "../../executor.config";import { DbService } from "../db/db";import { cloudDbProviderLayer } from "../db/fuma"; export { makeExecutionStack } from "@executor-js/api/server"; // The executor table set is fixed (plugin-independent), so the per-request// DbProvider rebuilds the fuma client over the same schema.export const CloudDbProvider = cloudDbProviderLayer(collectTables()); const cloudPluginFactory = executorConfig.plugins as (deps: {  readonly workosCredentials: {    readonly apiKey: string;    readonly clientId: string;    readonly apiUrl?: string;  };  readonly activeToolkitSlug?: string;}) => readonly AnyPlugin[]; // Fresh plugin instances per request, carrying the Worker env's WorkOS Vault// credentials. Matches the old `createScopedExecutor`'s `orgPlugins()`.export const CloudPluginsProvider: Layer.Layer<PluginsProvider> = Layer.succeed(PluginsProvider)({  plugins: (context) =>    cloudPluginFactory({      workosCredentials: {        apiKey: env.WORKOS_API_KEY,        clientId: env.WORKOS_CLIENT_ID,        apiUrl: env.WORKOS_API_URL,      },      activeToolkitSlug:        context?.mcpResource?.kind === "toolkit" ? context.mcpResource.slug : undefined,    }),}); /** * The path prefix the cloud mounts its typed API under. SINGLE SOURCE OF TRUTH: * `app.ts` passes this as `ExecutorApp.make({ config: { mountPrefix } })`, and * `make` derives the OAuth callback (`${webBaseUrl}${CLOUD_MOUNT_PREFIX}/oauth/callback`) * from that same `mountPrefix`, so the redirect URI the host sends to providers * always matches the route that actually serves the callback — no second knob. */export const CLOUD_MOUNT_PREFIX = "/api" as const; /** * Cloud's host config, parameterized by the ONE seam its two execution planes * genuinely disagree about: where a deferred tool-catalog refresh runs. * * The MCP session Durable Object holds its database handle for the life of the * session, so it can hand the batch straight to `ctx.waitUntil` and forget it. * The HTTP plane's handle dies with its request and gets no seam at all (see * {@link CloudHostConfig}). Nothing else about the config differs, which is why * this is a parameter rather than a second config module. */export const makeCloudHostConfig = (  deferToolSync: HostConfigShape["deferToolSync"],): Layer.Layer<HostConfig> =>  Layer.sync(HostConfig, () => ({    // SSRF / private-network egress guard. Config-driven, NOT a test flag:    // production leaves `ALLOW_LOCAL_NETWORK` unset so the guard stays ON (`false`);    // the e2e dev-server env opts in with `"true"` so in-scenario fixture    // servers on localhost are reachable. See `hosted-http-client.ts`.    allowLocalNetwork: env.ALLOW_LOCAL_NETWORK === "true",    webBaseUrl: env.VITE_PUBLIC_SITE_URL ?? "https://executor.sh",    oauthCallbackPath: `${CLOUD_MOUNT_PREFIX}/oauth/callback`,    // WorkOS Vault is cloud's credential storage implementation detail, not a    // user-selectable provider surface.    exposeCredentialProviders: false,    deferToolSync,  })); /** * The HTTP plane's config, and the one seam it CANNOT fill: `deferToolSync` is * absent, so a tools read over `/api/*` still refreshes an expired catalog * inline. * * Not an omission. The postgres pool a request's executor closes over is * acquired and released inside `requestScopedMiddleware`'s `Effect.scoped`, * which wraps the ROUTE HANDLER — so the pool is torn down while the handler's * `HttpServerResponse` is still a value, strictly before `HttpEffect.toHandled` * writes it. There is therefore no window on this plane that is both after the * response and before the socket closes: work scheduled with `waitUntil` finds * a dead pool, and work drained inside the scope is simply inline work with * extra steps. `api.request-scope.node.test.ts` pins that ordering, so a future * change to the request lifecycle will say so rather than making this comment * quietly wrong. * * Holding the pool open past the response instead — deferring the scope close * into `waitUntil` — is the one thing that would make the window exist, and it * is the thing `closePostgres` was written to prevent. That finalizer awaits * the teardown precisely so live-plus-closing sockets stay bounded by what is * in flight; unbounded, the backlog is the sustained-load cascade recorded in * `db/db.ts`. Trading a socket leak for a background refresh is not a trade * this plane should make, and it would make it on EVERY request, not just the * ones that deferred. * * The alternative — giving the batch a short-lived pool of its own via * `makeDbLayer()` — does not fit either: the task the sdk hands over is already * bound to the executor that built it, so re-targeting it means rebuilding a * whole second executor in the background. That is a background scheduler, a * different feature with a different failure surface, not a wiring detail. * * Cloud's high-volume tools read is `tools/list` over MCP, and that plane DOES * defer: the session Durable Object holds its database handle for the life of * the session (see `mcp/session-durable-object.ts`). */export const CloudHostConfig: Layer.Layer<HostConfig> = makeCloudHostConfig(undefined); export const CloudCodeExecutorProvider: Layer.Layer<CodeExecutorProvider> = Layer.sync(  CodeExecutorProvider,  () => makeDynamicWorkerExecutor({ loader: env.LOADER }),); /** * The four billing-free execution-stack seams (db / plugins / host-config / * code-executor): everything `makeExecutionStack` reads EXCEPT the * `EngineDecorator`. Both cloud planes compose this with the billing decorator * via `CloudMeteredExecutionStackLayer` (../engine/execution-stack-metered.ts); * exported so that overlay builds over the SAME four seams. There is no neutral * no-op-decorator variant anymore: every cloud execution meters. */export const makeCloudExecutionSeamsLayer = (  hostConfig: Layer.Layer<HostConfig>,): Layer.Layer<  DbProvider | PluginsProvider | HostConfig | CodeExecutorProvider,  never,  DbService> => Layer.mergeAll(CloudDbProvider, CloudPluginsProvider, hostConfig, CloudCodeExecutorProvider); export const CloudExecutionSeamsLayer: Layer.Layer<  DbProvider | PluginsProvider | HostConfig | CodeExecutorProvider,  never,  DbService> = makeCloudExecutionSeamsLayer(CloudHostConfig);