@fjall/components-infrastructure 9.0.0 → 10.1.1

package/dist/lib/patterns/aws/compute.js

@@ -173,6 +173,10 @@ export class ComputeFactory {
                     const collector = app.getManifestCollector();
                     const clusterName = id;
                     const appName = computeProps.appName ?? app.getName();
+                    // Buffered until after construction: only the EcsCompute ctor knows
+                    // whether each service materialised the schema-gate container (the
+                    // eligibility resolution needs the connected database constructs).
+                    const pendingManifestServices = [];
                     for (const service of computeProps.services) {
                         // Promote public-prefixed declared-env vars into docker.buildArgs
                         // (with their values) BEFORE the manifest copy and before the
@@ -220,9 +224,17 @@ export class ComputeFactory {
                                     cluster: clusterName,
                                     service: service.name
                                 });
+                        pendingManifestServices.push(manifestService);
+                    }
+                    const ecsCompute = new EcsCompute(scope, id, computeProps);
+                    for (const manifestService of pendingManifestServices) {
+                        const gateTag = ecsCompute.schemaGateImageTags.get(manifestService.name);
+                        if (gateTag !== undefined) {
+                            manifestService.schemaGateImageTag = gateTag;
+                        }
                         collector.addService(manifestService);
                     }
-                    return new EcsCompute(scope, id, computeProps);
+                    return ecsCompute;
                 }
                 case "lambda": {
                     // Add appName to props for Lambda (needed for secrets path derivation)

package/dist/lib/patterns/aws/computeEcs.d.ts

@@ -16,6 +16,24 @@ export declare function getEcsCapacityProviderConfig(provider: EcsCapacityProvid
  * Extracted for clarity and detail parity with database/network patterns.
  */
 export declare function validateEcsProps(props: EcsComputeProps): void;
+/**
+ * Resolved inputs for the synthetic `fjall-schema-gate` container. Produced by
+ * `EcsCompute.resolveSchemaGateMaterialisation`, consumed by
+ * `buildContainerConfigs` (topology wiring).
+ * @internal Exported for testing only
+ */
+export interface SchemaGateContainerSpec {
+    environment: Record<string, string>;
+    secretsImport: Record<string, SecretImport>;
+    image: string;
+    /**
+     * The exact package semver used to tag the DEFAULT gate image, absent when
+     * the author brought their own via `schemaGate.image`. Surfaced through
+     * `EcsCompute.schemaGateImageTags` into the fjall manifest so deploy-core's
+     * `ensureSchemaGateImage` knows which tag to mirror pre-deploy.
+     */
+    defaultImageTag?: string;
+}
 /**
  * Expand a service's `migrations` sugar into a synthetic init container plus
  * auto-injected `dependsOn` entries on every other container.
@@ -47,12 +65,17 @@ export declare function expandMigrationsSugar(service: EcsServiceConfig, userCon
  * @param annotationsScope Construct used as the source for synth-time
  *                      warnings when the author has set `EXPECTED_SCHEMA_VERSION`
  *                      themselves and the resolved value differs.
+ * @param schemaGate    Resolved spec for the synthetic `fjall-schema-gate`
+ *                      container, or `undefined` when materialisation is off
+ *                      (opted out, ineligible, or nothing to gate). When set,
+ *                      the gate container is prepended and every non-migrate
+ *                      container gains a `dependsOn` SUCCESS edge on it.
  * @internal Exported for testing only
  */
 export declare function buildContainerConfigs(service: EcsServiceConfig, schemaVersionEnv?: Record<string, string>, annotationsScope?: Construct, chGate?: {
     environment: Record<string, string>;
     secretsImport: Record<string, SecretImport>;
-}): EcsClusterProps["services"][number]["containers"];
+}, schemaGate?: SchemaGateContainerSpec): EcsClusterProps["services"][number]["containers"];
 /**
  * Resolved scaling configuration for an ECS service.
  * @internal Exported for testing only
@@ -80,6 +103,15 @@ export declare class EcsCompute extends Construct implements IEcsCompute {
     private readonly clusterId;
     private readonly appName;
     private readonly migrationTaskDefinitions;
+    /**
+     * Service name → exact `@fjall/schema-gate` semver, for every service that
+     * materialised the gate container with the DEFAULT image this synth.
+     * ComputeFactory copies it onto the manifest entry (`schemaGateImageTag`)
+     * so deploy-core's `ensureSchemaGateImage` mirrors the tag pre-deploy.
+     * BYO-image services (`schemaGate.image`) are deliberately absent — the
+     * author owns that image's availability.
+     */
+    readonly schemaGateImageTags: ReadonlyMap<string, string>;
     constructor(scope: Construct, id: string, props: EcsComputeProps);
     /**
      * Walks a service's `connections:` for a relational database carrying a
@@ -113,8 +145,55 @@ export declare class EcsCompute extends Construct implements IEcsCompute {
      * - Two or more migrated CHs → throws via `resolveClickHouseDatabaseForService`
      */
     private resolveClickHouseSchemaVersionEnv;
+    /**
+     * Decide whether the synthetic `fjall-schema-gate` container materialises
+     * for this service, and compose its env/secrets/image when it does.
+     * Returns `undefined` (env-injection-only, the pre-10.x behaviour) when:
+     *
+     * - `schemaGate: false` or `{ materialise: false }` (author opt-out)
+     * - Neither a PG nor a CH gate resolved for the service
+     * - `migrations.mode: "post-deploy"` — expected is deliberately ahead of
+     *   the DB during scale-up, so a materialised gate would refuse every task
+     *   (synth warning)
+     * - `migrations.mode: "lifecycle-hook"` WITHOUT `separateTaskDef` — the
+     *   hook's migration RunTask reuses the service task definition, so a
+     *   materialised gate would refuse the migration task itself while the DB
+     *   still holds the pre-migration schema (synth warning; adding
+     *   `separateTaskDef` restores full gating)
+     * - No eligible half survives the v1 scope filters: the relational half
+     *   requires `tool: "prisma"` and a postgres-family connection scheme
+     *   (per-half synth warnings; env injection into app containers stays on)
+     * - The default image URI cannot be derived because the constructs package
+     *   version is unresolvable and no `schemaGate.image` override is set
+     *
+     * The relational half re-resolves the migrated DB for its
+     * `getSchemaGateContribution()` (credential-free URL base + user/password
+     * secret imports). The CH half composes `CLICKHOUSE_URL` / database name /
+     * CA-cert import from the resolved CH database — `chGate` alone carries
+     * only the version + schema-admin entries the app containers get.
+     */
+    private resolveSchemaGateMaterialisation;
     private materialiseScheduledTasks;
     private buildScheduledTaskDefinition;
+    /**
+     * Compose a scheduled task's container env and secrets: schema-version gate
+     * env resolved from the entry's `connections` merges beneath the author's
+     * `environment` (author wins — the same semantics as service containers),
+     * and the ClickHouse gate's credential imports merge beneath the author's
+     * `secrets`. Returns `undefined` halves when nothing applies so the
+     * container definition stays byte-identical for unconnected entries.
+     */
+    private composeScheduledTaskEnvAndSecrets;
+    /**
+     * A sibling service that consumes a hook-migrated database materialises a
+     * schema gate that refuses while the owner's migration is still in flight.
+     * Without `awaitMigrationsFrom` the sibling rolls out in parallel with the
+     * owner, so its gate-refused task churn can trip the deployment circuit
+     * breaker before the migration lands. The gate refusing is by design (new
+     * code must not serve the old schema); the missing DependsOn is the
+     * author-fixable part — warn, don't disable.
+     */
+    private warnUngatedSiblingsOfHookOwners;
     /**
      * For each service whose `migrations.mode` is a lambda-hook variant
      * (`"lifecycle-hook"` for PRE_SCALE_UP, `"post-deploy"` for POST_SCALE_UP),