https://serverless-stack.com/ logo
Join Slack
Powered by
Does `stage` have a character limit? We use person...
# sst
d
Does 
stage
have a character limit? We use personal stages for local dev, and mine is 
derekkershner
, and I received an error while 
sst start
ing: 
Error: Function name can not be longer than 64 characters but has 66 characters.
. This deploys fine to 
prod
stage.
s
Isn't the function name a combination of a number of things?
the stage, app name, a random component?
d
yes, but every other piece should be the same between stages.
s
ahh, I see your point
Looks like Lambda Functions have a 64 character limit (per the Cloudformation docs- and you've correctly noted)
I suppose your stage name could push it over the limit, depending on the length of your other variables
d
Fixing this is not too hard, just trying to figure out SST’s intent and fix it for all of our devs at once. I assumed SST would truncate the last piece based on the limit, but perhaps it assumes a stage name that is shorter?
on a completely unrelated note, anyone know how to write a bash script to truncate 
$(whoami)
to a number of characters?
a
whoami|head -c 8
cut
is another option
d
always coming through, @Adam Fanello, spot on.
also, shortening the stage name does indeed fix the bug
n
Is the random component necessary? I’m adding a NextJS site into a large organization’s AWS environment and the dev-ops folks are complaining about… 
myname-myapp-CustomS3AutoDeleteObject-fvOyFB3nyCdg
vs 
myname-myapp-CustomS3AutoDeleteObject
. In general they’re complaining about so many lambda functions between local devs, dev, and prod, but that’s a different complaint.
a
(The additional lambda for every lambda to manage CloudWatch logs is annoying. Would love to have just one per stack instead.)
But agree with Nickie too. What is the point of the random bit?
d
Maybe ask in a separate thread, no one seems to be showing up to this one.
a
This Slack has become very crowded - project is getting popular! I have some magic though. Here it goes. Watch this. 🪄 @thdxr
t
lol
I agree with the part about the random bit - I personally hate it! Unfortunately it's something CDK does because technically you can have two functions with the same name, one in the stack and one in a nested construct. I do think CDK could have tried to handle this better by doing 
app-stage-stack-{path}
where path is the id of every parent resource but I think at some point it gets too long so they opt for a hash of the path
d
No doubt, and these guys are great to do so much chatting, but I try to let them respond async where possible. `thdxrQueue.publish`()
t
^ at an old company I worked at people tagged messages with #async and I'd search for those every few hours haha
d
Perfect!
t
The hash thing makes a mess of the AWS console + the cloudwatch logs etc, it's why our console only ever shows everything by its cloudformation ID. Unfortunately AWS's console does not commit to cloudformation so they show the underlying resource name
f
Hey guys.. haha prepping for the v1 launch has been more work than anticipated 😅
(The additional lambda for every lambda to manage CloudWatch logs is annoying. Would love to have just one per stack instead.)
Do you guys prefer having 1 Lambda per stack to set log retention? Or if SST deployed an 
SSTToolkit
Stack per account per region (like 
CDKToolkit
), and it sets the log retention for all app in the same account/region?
The stack is self-contained in the former case.
d
Hey guys.. haha prepping for the v1 launch has been more work than anticipated 😅
Optimists till the end, the whole lot of us Developers. 🙂
Do you guys prefer having 1 Lambda per stack to set log retention? Or if SST deployed an 
SSTToolkit
Stack per account per region (like 
CDKToolkit
), and it sets the log retention for all app in the same account/region?
I do not share the OCD of the others, and prefer a lambda to have a single purpose, and also do not care about random characters in names (unless they make me exceed function name limits, which is the original bug I was trying to report 😉 )
f
Got it! Did u get the error at build time or CFN complained on deploy time?
a
Do you guys prefer having 1 Lambda per stack to set log retention? Or if SST deployed an 
SSTToolkit
Stack per account per region (like 
CDKToolkit
), and it sets the log retention for all app in the same account/region?
I'm good either way, so long as there aren't double the Lambdas all with cryptic names. If there are other things you can do with specialized Lambdas, then a SSTToolkit stack can consolidate it. If it's just about Lambda logs, and never anything else, then including with stacks that have Lambdas makes sense.
Open in Slack
PreviousNext
Powered by