@go-to-k/cdkd 0.30.1 → 0.31.0

package/dist/index.js

@@ -6754,7 +6754,11 @@ Error: ${err.message || "Unknown error"}`,
 };
 
 // src/provisioning/providers/custom-resource-provider.ts
-import { InvokeCommand } from "@aws-sdk/client-lambda";
+import {
+  InvokeCommand,
+  waitUntilFunctionActiveV2,
+  waitUntilFunctionUpdatedV2
+} from "@aws-sdk/client-lambda";
 import { PublishCommand } from "@aws-sdk/client-sns";
 import {
   S3Client as S3Client6,
@@ -7038,9 +7042,54 @@ var CustomResourceProvider = class _CustomResourceProvider {
       await this.publishToSns(serviceToken, request);
       return await this.pollS3Response(responseKey, logicalId, operation);
     }
+    await this.waitForBackingLambdaReady(serviceToken, logicalId);
     const response = await this.invokeLambda(serviceToken, request);
     return await this.getCustomResourceResponse(response, responseKey, logicalId, operation);
   }
+  /**
+   * Block until the backing Lambda function for a Custom Resource is in a
+   * state that accepts a synchronous Invoke.
+   *
+   * Two sequential waiters:
+   *   1. `waitUntilFunctionActiveV2` — handles the post-CreateFunction
+   *      `Pending` window (image pull, VPC ENI attachment, layer init).
+   *   2. `waitUntilFunctionUpdatedV2` — handles the post-Update
+   *      `InProgress` window (configuration / code swap settling).
+   * Together they cover the only two transient states that reject
+   * synchronous Invokes.
+   *
+   * In the common case (Lambda has been Active for a while, no in-flight
+   * Update), both waiters return on first poll → ~2 GetFunction calls →
+   * ~200ms overhead. That's the price for correctness; the alternative
+   * (whole-stack Active wait at Lambda CREATE) is ~5–10 minutes per
+   * VPC-attached function.
+   *
+   * `serviceToken` is the Lambda function ARN; the Lambda SDK accepts
+   * both name and ARN as `FunctionName`, so we pass the ARN through
+   * unchanged.
+   *
+   * `maxWaitTime` is set generously (10 min) because VPC ENI attachment
+   * has been observed to take 8+ minutes in pathological cases. The
+   * deploy engine's per-resource `--resource-timeout` (default 30 min)
+   * still bounds the outer Custom Resource provisioning attempt, so
+   * this waiter cap is layered defense, not the only timeout.
+   */
+  async waitForBackingLambdaReady(serviceToken, logicalId) {
+    try {
+      await waitUntilFunctionActiveV2(
+        { client: this.lambdaClient, maxWaitTime: 600 },
+        { FunctionName: serviceToken }
+      );
+      await waitUntilFunctionUpdatedV2(
+        { client: this.lambdaClient, maxWaitTime: 600 },
+        { FunctionName: serviceToken }
+      );
+    } catch (error) {
+      throw new Error(
+        `Lambda backing custom resource ${logicalId} (${serviceToken}) did not reach a ready state for Invoke: ${error instanceof Error ? error.message : String(error)}`
+      );
+    }
+  }
   /**
    * Publish custom resource request to an SNS topic
    */