I am attempting to update from 0.53.0 -> 0.54.0...
# help
k
I am attempting to update from 0.53.0 -> 0.54.0 (and eventually to 1.x) and running into an issue with this error:
ERROR build_failure: The function [FUNCTION_NAME] failed to build
when I invoke the associated endpoint. It is a Go lambda. I have the sst.json at the root of my repo, and then the go code is in a subfolder "foo". The srcPath prop is set to "foo". Any ideas?
f
Hi @Kelly Davis, does this happen only in 0.54.0. You were able to build in 0.53.0?
k
HI 👋 yes, 0.53.0 was the last version that worked. I didn't try it yet with 0.53.x, but 0.54.0 and 0.54.4 both exhibited the same behavior. I am currently trying 0.57.0 - just waiting for it to finish updating my stacks
I do see the lambda in the .sst/functions.jsonl file and they seem to have the correct values for srcPath, root, handler
ok, 0.57.0 is still doing it 😕
f
yeah maybe give that a try
k
ok... that's a big one 🙂
f
0.59.0 also has the CDK v2 change, lemme know if u need help with changing the package.json and imports
k
one issue I keep running into is that
npx sst update x.x.x
does not make any changes to the package json. For example, I just ran it and I got:
Copy code
Updating @serverless-stack/cli to 0.59.1
Updating @serverless-stack/resources to 0.59.1
Updating @aws-cdk/assert@1.138.0
Updating @aws-cdk/aws-iam@1.138.0
Updating @aws-cdk/aws-ses@1.138.0
Updating @aws-cdk/aws-wafv2@1.138.0
Updating @aws-cdk/core@1.138.0
SST: 0.57.4
CDK: 1.138.0
f
can you show me ur package.json?
k
yeah, let me DM it
f
got it. 1. Change these 2 lines
Copy code
"@serverless-stack/cli": "0.59.1",
    "@serverless-stack/resources": "0.59.1",
2. Remove all
@aws-cdk/*
ones 3. Add
Copy code
"aws-cdk-lib": "2.7.0",
k
👍
I think I've got everything updated but I am running into this error deploying:
Copy code
kldavis-tina-cloud-stack-debug-stack: deploying...

 ❌  kldavis-tina-cloud-stack-debug-stack failed: Error: kldavis-tina-cloud-stack-debug-stack: This CDK deployment requires bootstrap stack version '6', found '5'. Please run 'cdk bootstrap'.
    at CloudFormationDeployments.validateBootstrapStackVersion (/Users/kldavis/projects/teams-serverless/node_modules/aws-cdk/lib/api/cloudformation-deployments.ts:440:13)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at CloudFormationDeployments.publishStackAssets (/Users/kldavis/projects/teams-serverless/node_modules/aws-cdk/lib/api/cloudformation-deployments.ts:415:7)
    at CloudFormationDeployments.deployStack (/Users/kldavis/projects/teams-serverless/node_modules/aws-cdk/lib/api/cloudformation-deployments.ts:262:5)
    at CdkToolkit.deploy (/Users/kldavis/projects/teams-serverless/node_modules/aws-cdk/lib/cdk-toolkit.ts:199:24)
    at initCommandLine (/Users/kldavis/projects/teams-serverless/node_modules/aws-cdk/bin/cdk.ts:268:9)
kldavis-tina-cloud-stack-debug-stack: This CDK deployment requires bootstrap stack version '6', found '5'. Please run 'cdk bootstrap'.

 ❌  kldavis-tina-cloud-stack-debug-stack failed: The kldavis-tina-cloud-stack-debug-stack stack failed to deploy.
I tried deleting the debug stack but it didn't resolve it. Does this mean the CDKToolkit stack needs to be updated?
I tried running
sst cdk bootstrap
but I get this error:
Copy code
Error: construct does not have an associated node. All constructs must extend the "Construct" base class
    at Function.of (/Users/kldavis/projects/teams-serverless/node_modules/constructs/src/construct.ts:21:13)
    at new Node (/Users/kldavis/projects/teams-serverless/node_modules/constructs/src/construct.ts:58:12)
    at Object.createNode (/Users/kldavis/projects/teams-serverless/node_modules/constructs/src/construct.ts:407:91)
    at new Construct (/Users/kldavis/projects/teams-serverless/node_modules/constructs/src/construct.ts:409:26)
    at new Resource (/Users/kldavis/projects/teams-serverless/node_modules/aws-cdk-lib/core/lib/resource.ts:70:5)
    at new TableBase (/Users/kldavis/projects/teams-serverless/node_modules/aws-cdk-lib/aws-dynamodb/lib/table.ts:277:1)
    at new Table (/Users/kldavis/projects/teams-serverless/node_modules/aws-cdk-lib/aws-dynamodb/lib/table.ts:680:5)
    at IdentityStack.createDynamoTable (/Users/kldavis/projects/teams-serverless/sst/IdentityStack.ts:526:23)
    at new IdentityStack (/Users/kldavis/projects/teams-serverless/sst/IdentityStack.ts:78:30)
    at Object.main (/Users/kldavis/projects/teams-serverless/sst/index.ts:87:25)
This is originating where a dynamodb table is being created
So the construct error was resolved by adding constructs@10.1.24 to the devDependencies. (We were importing Construct from @aws-cdk/core previously). After running bootstrap the stacks deployed successfully and the original error about the function failing to build was resolved
f
Glad u feel got it to work.
You shouldn’t need to add
constructs
as a devDep. Feel free to show me the repo if you need anohter pair of eyes 🙂
k
where can I import Construct from without it as a dependency?
f
where r u importing Construct?
k
we are doing something like this: https://stackoverflow.com/a/63559786/290918
f
the scope for ur Stacks should be the
app
and the scope for the constructs in a stack should be the
stack
k
Here's our current implementation:
Copy code
export class SsmParameterReader extends Construct {
  private reader: AwsCustomResource

  constructor(scope: Construct, name: string, props: SsmParameterReaderProps) {
    super(scope, name)

    const { parameterName, region } = props

    this.reader = new AwsCustomResource(scope, `${name}CustomResource`, {
      policy: AwsCustomResourcePolicy.fromStatements([
        new iam.PolicyStatement({
          effect: iam.Effect.ALLOW,
          actions: ['ssm:GetParameter*'],
          resources: [
            sst.Stack.of(this).formatArn({
              service: 'ssm',
              region,
              resource: 'parameter',
              resourceName: parameterName.replace(/^\/+/, ''), // remove leading '/', since formatArn() will add one
            }),
          ],
        }),
      ]),
      onUpdate: {
        service: 'SSM',
        action: 'getParameter',
        parameters: {
          Name: parameterName,
        },
        region,
        physicalResourceId: PhysicalResourceId.of(Date.now().toString()), // Update physical id to always fetch the latest version
      },
    })
  }

  private getParameterValue(): string {
    return this.reader.getResponseField('Parameter.Value')
  }

  get stringValue(): string {
    return this.getParameterValue()
  }
}
So what should we be extending instead of Construct?
f
Ah my bad.. u r actually creating a custom construct.
can I see how u r using the
SsmParameterReader
?
k
we have a separate stack that manages an lambda@edge for frontend security and that writes its version out:
Copy code
new ssm.StringParameter(this, 'ssm-value', {
      parameterName: <param-name>,
      stringValue: `${cloudfrontSecurity.functionArn}:${cloudfrontSecurity.currentVersion.version}`,
    })
and then in the frontend stack we read the current version:
Copy code
const egdeLambdaFunctionArn = new SsmParameterReader(
        this,
        'LambdaFunctionArnReader',
        {
          parameterName: <param-name>,
          region: 'us-east-1', // lambda@edge region
        }
      ).stringValue
the lambda@edge is rarely updated, so this avoids having cloudformation update it when the frontend stack is updated
f
I see.. and are
this
in both cases
Stack
?
k
yep, sst.Stack in both cases
f
in that case, u can replace
Copy code
constructor(scope: Construct, name: string, props: SsmParameterReaderProps) {
with
Copy code
constructor(scope: sst.Stack, name: string, props: SsmParameterReaderProps) {
there’s nothing wrong with importing
Construct
and including it as a devDep.. but u’d have to manually keep
construct
’s version up to date
the latter will save u some hassle down the road
k
ok, cool - what about about the
extends
?
f
oops.. my bad.. i guess there’s no way around this… unless we expose an
sst.Construct
k
internally sst is using a vendored version of constructs, right?
f
yup
k
yeah, if that version was exported it would allow us to stay in sync
f
yeah… maybe keep ur code as is for now… and lemme know if u run up against issues in the future
k
sounds good 👍