https://serverless-stack.com/ logo
Join Slack
Powered by
errors thrown in the stack code doesn’t seem to st...
# help
s
errors thrown in the stack code doesn’t seem to stop the build process.
t
this is on 
sst build
?
s
yeah
t
Will make an issue
s
thanks!
t
Working on this now - where was the error happening?
Was it in your function code? Or in the stack code
Ah were you using a promise somewhere in the constructor of a stack?
s
I don't remember but I'll check when I get into the office
@thdxr ok, still seeing this. how do we troubleshoot this? there are no async parts as far as I can tell
Copy code
[dotenv][DEBUG] did not match key and value when parsing line 1: # These variables are only available in your SST code.
[dotenv][DEBUG] did not match key and value when parsing line 2: # To apply them to your Lambda functions, checkout this doc - <https://docs.serverless-stack.com/environment-variables#environment-variables-in-lambda-functions>
[dotenv][DEBUG] did not match key and value when parsing line 3:
[dotenv][DEBUG] did not match key and value when parsing line 7:
there may be async stuff at some point.. my stack will likely have to use SSM to fetch parameters from the primary AWS account, which is async
t
Got it. For fetching SSM params I recommend doing that in the app, not the stack. Since the Stack API is built around doing everything in the constructor, nothing in there should be async since constructors cannot await on async code.
That's separate from anything SST related. On the SST side I tried to recreate the issue by spawning a promise in the constructor that fails after 5 seconds and couldn't recreate your issue
s
I didn’t wanna introduce more latency in our Lambda funcs by fetching SSM params there. w/ Serverless Framework, I typically use their 
${ssm:xx}
vars.
t
Sorry by app I meant sst.App
s
ohh gotcha
t
example
Just an FYI in case you're not aware. Not everyone requires this level of security but pulling SSM params out and putting them into environment variables sort of eliminates any benefit from storing them there. What I do is load that in the function once and keep it cached. That way it only adds latency to cold starts vs normal invocation
s
oh, cool. thanks! just a warning BTW, I don’t know if aws-sdk v2 does proper tree-shaking when you do 
import { X } from 'aws-sdk'
. I think you have to do 
import { SSM } from 'aws-sdk/clients/ssm'
. but even better, is using the v3 SDK:
Copy code
import { SSMClient, GetParameterCommand } from '@aws-sdk/client-ssm';

// ...
const ssm = new SSMClient({});
const data = await ssm.send(new GetParameterCommand({ ... }));
t
I did do a test with that and esbuild is able to treeshake it when importing directly from 
aws-sdk
googleapis
on the other hand....accidentally added 10mb to my code lol
s
ah it does.. gotcha. maybe it was webpack that couldn’t do it 😉
wow
and yeah I realize storing the stuff in Lambda env vars isn’t ideal. but if our AWS accounts are secured properly, it’s not a big deal. I’m not concerned about hired devs seeing that either, since they could just as easily just make an API call to grab params from the primary account anyway. unless I’m missing something
though, another benefit is not having to redeploy to update those env vars. if it’s fetched at runtime, I can just change params and it’s done
t
Yeah I have mine polling SSM every 1 min to refresh near instantly
s
but you’re right, as long as the params are cached in the global func space, that should be sufficient so it’s there on a warm start
t
And the main difference is that fetches to SSM are more audited so if someone steals creds you can trace it back. Doesn't stop anything but a requirement if you're running in a compliant environment. Last 2 companies I was at needed HITRUST and PCI so I tend to be annoying about these things
But probably overkill for most people
s
why poll SSM? if it’s Lambda, it’ll just grab the updated secret next time it runs, no? or you mean to cover cases where the func is only doing warm starts and not updating the param?
t
Yeah the latter
s
so you have something like a 
lastFetched
var to keep track in the function?
and if it’s stale, it’ll fetch again
t
That maybe is a better way to do it but I just had a quick implementation with setInterval polling every 1min
s
good point on PCI compliance. I probably should go that route.. we should be legally buttoned up
oh BTW, I figured out those warnings. it didn’t like the 
# comments
in the .env file.
those were there when I created the SST project
t
ah interesting
s
though I’m still getting one more:
Copy code
[dotenv][DEBUG] did not match key and value when parsing line 4:
no details as to what’s wrong. this is my .env file:
Copy code
APP_NAME=reelcrafter
DOMAIN=<http://reelcrafter.com|reelcrafter.com>
SSM_ROLE_ARN=arn:aws:iam::xx:role/sub-account-ssm-reader
4 Views
Open in Slack
PreviousNext
Powered by