https://serverless-stack.com/ logo
Join SlackCommunities
Powered by
```export default class APIStack extends sst.Stack...
# sst
k
Copy code
export default class APIStack extends sst.Stack {
  constructor(scope: <http://sst.App|sst.App>, id: string, props?: sst.StackProps) {
    super(scope, id, props);

    // Create the HTTP API
    const api = new sst.Api(this, "Api", {
      defaultFunctionProps: {
        runtime: lambda.Runtime.NODEJS_14_X,
      },
      routes: {
        "GET /whoami": "src/api/lambda.whoami",
      },
    });
f
What’s the error you are getting?
k
Error: The specified runtime is not supported for sst.Function. Only NodeJS runtimes are currently supported.
I'm using the latest sst version.
f
can I see how you are importing lamba?
k
Copy code
import * as cdk from "@aws-cdk/core";
import * as sst from "@serverless-stack/resources";
import * as lambda from "@aws-cdk/aws-lambda";
f
Can I also see your package.json also?
k
in the debugger, the value for the runtime shows as this
Copy code
{
  "name": "xxx",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "test": "sst test",
    "start": "sst start --stage=${USER}",
    "build": "sst build",
    "deploy": "sst deploy",
    "remove": "sst remove"
  },
  "devDependencies": {
    "@aws-cdk/assert": "1.89.0",
    "@types/aws-lambda": "^8.10.72"
  },
  "dependencies": {
    "@aws-cdk/core": "1.89.0",
    "@serverless-stack/cli": "0.9.5",
    "@serverless-stack/resources": "0.9.5"
  }
}
f
hmm that’s weird.. let’s try this quickly
let’s add a debug msg
go to ur node_module > @serverless-stack/resources > dist > Function.js
Can you open this file up?
k
yep
f
if u search for the string “The specified runtime is not …”
k
yeah i'm there
f
See it?
nice
let’s add this above the if block:
Copy code
console.log("my runtime", runtime);
console.log("node14 runtime", lambda.Runtime.NODEJS_14_x);
k
Copy code
Runtime2 {
  name: 'nodejs14.x',
  supportsInlineCode: false,
  family: 0,
  bundlingDockerImage: BundlingDockerImage {
    image: 'amazon/aws-sam-cli-build-image-nodejs14.x',
    _imageHash: undefined
  },
  supportsCodeGuruProfiling: false
}
that's what i showed with the debugger, they look like the same
let me do it with your lines
f
yeah.. and try build again
k
Copy code
my runtime Runtime2 {
  name: 'nodejs14.x',
  supportsInlineCode: false,
  family: 0,
  bundlingDockerImage: BundlingDockerImage {
    image: 'amazon/aws-sam-cli-build-image-nodejs14.x',
    _imageHash: undefined
  },
  supportsCodeGuruProfiling: false
}
node14 runtime undefined
hmm undefined
f
ah yeah.. that makes sense… for some reason it’s using an old version of CDK lambda package
k
oh upper X needed
f
oh ic
k
Copy code
my runtime Runtime2 {
  name: 'nodejs14.x',
  supportsInlineCode: false,
  family: 0,
  bundlingDockerImage: BundlingDockerImage {
    image: 'amazon/aws-sam-cli-build-image-nodejs14.x',
    _imageHash: undefined
  },
  supportsCodeGuruProfiling: false
}
node14 runtime Runtime {
  name: 'nodejs14.x',
  supportsInlineCode: false,
  family: 0,
  bundlingDockerImage: BundlingDockerImage {
    image: 'amazon/aws-sam-cli-build-image-nodejs14.x',
    _imageHash: undefined
  },
  supportsCodeGuruProfiling: false
}
why Runtime2?
f
hmm the SST code is flawed… it shouldn’t test against object
it should just compare the runtime name
u can comment out this if block for now… i think that should work
Let me put in a fix now
k
cool, we can wait for the fix, thanks for checking
f
Actually, can you add 
"@aws-cdk/aws-lambda": "1.89.0",
to ur package.json?
It think you are currently piggy-bagging on a 
aws-lambda
module from other package’s dependency.
k
yeah that was it!
f
Yeah lemme talk to the team. This is obviously confusing and hard to debug.
k
i'm getting started with JS/TS, wondering how that other version got it there
oh it seems like it came from another dev.. so another story
thanks for checking @Frank
f
👍
We are thinking about integrating 
sst start
into IDEs.
Out of curiosity, what IDE r u using?
k
We use WebStorm and VS Code
what i sent was from VS Code debugger
m
Yea, getting 
sst start
to run from VS Code was really easy @Frank
f
Oh nice. When running 
sst start
in VS Code can you set break points in ur function code to step through the code?
m
yea, that's how we found the type mismatch. We set a breakpoint and inspected the variable. VS Code was then set to pause execution at handled exceptions and we were able to inspect the 
includes
check in your library code
f
Oh I see. But the API request timed out while the function code paused at the break point right?
m
Well since what we were checking was throwing an exception, the API never started. But yes, if the service was live, we would be able to step through a request. However if the debug session was > timeout, the request will time out
f
Ah got it! Yeah im thinking when running in 
sst start
mode, set Lambda timeout to max (ie. 15min) to give ppl a bit more time to debug without breakpoints without timing out the request.
m
Yea, that's the way to go. Or at least allow it to be overridden with a parameter (sometimes you may want your local dev to timeout)
f
Yup makes sense!
m
Thanks for the work on this, we are really enjoying it so far. Also thanks for the quick issue turnaround
f
For sure! Appreciate for bringing it up!
Open in Slack
PreviousNext
Powered by