feat(cli): can ignore errors and return dummy value in CloudControl API context provider

[go-to-k]

CDK app with CC API Context Provider fails if the resource we want to get doesn't exist.

[Error at /LookupStack] Encountered CC API error while getting resource MyLookupTestRole. Error: ResourceNotFoundException: AWS::IAM::Role Handler returned status FAILED: The role with name MyLookupTestRole cannot be found. (Service: Iam, Status Code: 404, Request ID: xxxx-xxx-xxxx-xxxx) (HandlerErrorCode: NotFound, RequestToken: xxxx-xxx-xxxx-xxxx)

Also CC API Context Provider (CcApiContextProviderPlugin) cannot ignore errors even if ignoreErrorOnMissingContext is passed in aws-cdk-lib because the current code in aws-cdk-cli doesn't handle the property.

Sample cdk-lib code (based on my PR for IAM Role fromLookup):

    const response: {[key: string]: any}[] = ContextProvider.getValue(scope, {
      provider: cxschema.ContextProvider.CC_API_PROVIDER,
      props: {
        typeName: 'AWS::IAM::Role',
        exactIdentifier: options.roleName,
        propertiesToReturn: [
          'Arn',
        ],
      } as cxschema.CcApiContextQuery,
      dummyValue: [
        {
          // eslint-disable-next-line @cdklabs/no-literal-partition
          Arn: 'arn:aws:iam::123456789012:role/DUMMY_ARN',
        },
      ],
      ignoreErrorOnMissingContext: options.returnDummyRoleOnMissing, // added
    }).value;

However it would be good if the provider can ignore errors and return any dummy value to cdk library. This allows all resources to be used if available, or created if not.

Actually, SSM and KMS provider can ignore errors:

KMS: https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/context-providers/keys.ts#L43-L48

SSM: https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/context-providers/ssm-parameters.ts#L27-L30

For example, in cdk-lib, we can specify ignoreErrorOnMissingContext in the fromLookup. The dummyValue and ignoreErrorOnMissingContext properties can also be specified in GetContextValueOptions.

cli-integ

aws/aws-cdk-cli-testing#50

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[rix0rrr]

Passing the individual fields of type string, instead of the containing struct with fields of type string | undefined, was done exactly so that we could centralize the "do the fields make sense" logic into one place and proceed under the certainty that we have types that make sense; so that we don't have to have sneaky ! operators in downstream code that are hard to miss.

If you really feel that it becomes too onerous to pass all fields of this struct, then define a local type alias with a tester, and pass that instead:

type CcApiContextQueryList = Required<Pick<CcApiContextQuery, 'Identifier' | 'typeName' | 'propertyMatch' | ... >>;

function isListQuery(x: CcApiContextQuery): x is CcApiContextQueryList {
  return /* ... */;
}

[rix0rrr]

Should this behavior be in a try/catch in getValue() ? It seems duplicated.

[rix0rrr]

Also: let's decide what a good error protocol would be here. I'm not convinced that return a single dummy object (which a caller has to supply a value for, and then has to test for that value... and it needs to be different from the default dummy object) is the best protocol.

Also; context provider return values are usually cached. Do we really want "not found" dummy values to be cached? (I.e., if they notice and create the resource after the first synth, we will still behave as if the resource doesn't exist).

Is that behavior going to match expected user behavior?

[rix0rrr]

Use satisfies instead of as everywhere.

[rix0rrr]

I'm confused. Shouldn't these fields be part of CcApiContextQuery itself?

Why do we define them only for the tests, and access them with introspection in getDummyValueIfErrorIgnored ?