https://serverless-stack.com/ logo
Join Slack
Powered by
hey there — been getting error ```[50%] fail: No b...
# help
j
hey there — been getting error
Copy code
[50%] fail: No bucket named 'cdk-hnb659fds-assets-**-us-east-2'. Is account ** bootstrapped?
after nuking all the resources in my account and running 
sst start
. After getting this error, I tried running 
cdk bootstrap
and that worked just fine, but then running `sst start`would give the same error. Any idea of what could be going on here?
f
Try running this 
CDK_NEW_BOOTSTRAP=true cdk bootstrap
j
even so, same
Copy code
CDK_NEW_BOOTSTRAP set, using new-style bootstrapping
 ⏳  Bootstrapping environment <aws://522343907950/us-east-2>...
Trusted accounts:   522343907950
Execution policies: arn:aws:iam::522343907950:policy/ScopePermissions
 ✅  Environment <aws://522343907950/us-east-2> bootstrapped (no changes).
✨  Done in 2.29s.
f
Can you check if the bucket exists? ‘cdk-hnb659fds-assets-**-us-east-2’
j
it doesn’t! just checked by creating one with the same name and then deleting it
f
I see. Can you go into ur CloudFormation console and see if the CDKToolkit stack is there?
j
hmm it actually does!
f
I wonder what happened to the bucket.
Try delete the stack and run 
CDK_NEW_BOOTSTRAP=true cdk bootstrap
j
so it probably got deleted when I nuked my dev account, but that didn’t delete the CF stack for some reason
yup, doing it rn
interestingly seeing an error I hadn’t seen before
Copy code
Resource handler returned message: "Invalid request provided: Queue visibility timeout: 30 seconds is less than Function timeout: 900 seconds (Service: Lambda, Status Code: 400, Request ID: 9845a30e-6415-4522-a679-7372a3b20ea4, Extended Request ID: null)" (RequestToken: 5bcb9c53-ddfb-e580-3ada-301d21428746, HandlerErrorCode: InvalidRequest)
f
Oh, that’s an issue on our side.
We made a change in the last update to set the Lambda timeout to 900s when deployed with 
sst start
. So ppl have more time to debug using breakpoints.
j
and then also interestingly, when trying to start again it actually tries to create those resources again
f
tries to create those resources again
Do you mean the resources in the CDKToolkit or in ur app?
j
hmm that makes sense. Do you have any opinions about how to fix this issue with sqs timeout?
@Frank sorry, was not specific enough here. I mean the resources defined by my stack. E.g. when I ran sst start again, it actually tried to create a bucket that it had already created the first time, and then creation failed and started rolling back
f
Yeah, i think we can either: • not extend the timeout if it’s a Queue subscriber • or; also extend the visibility timeout for the queue as well
j
oh right, I didn’t even assume we could increase the visibility timeout. I’ll try that out as well
oh nvm, the bucket thing was an error on my end
f
When u run 
sst start
, under the 
Deploying app
section, do you see
Copy code
... | UPDATE_IN_PROGRESS | AWS::CloudFormation::Stack | ...
for the stack that has the S3 bucket; or do you see
Copy code
... | CREATE_IN_PROGRESS | AWS::CloudFormation::Stack | ...
Yeah, let me rollout a fix for the visibility timeout issue in the next release.
j
ok, for the time being I just increased the queue visibility timeout to 900s as well. Thanks for the help here 🙂
f
Hey @José Ribeiro, I pushed out a fix in 0.26.0. We no longer automatically set the lambda timeout to 900s when running inside 
sst start
. You can still use the 
--increase-timeout
flag to set the Lambda timeout to 900s. The flag will also automatically increase the queue visibility timeout to 900s to avoid the issue you ran into.
k
Just ran into the same issue with 
No bucket named 'cdk-hnb659fds-assets-**-us-east-2'. Is account ** bootstrapped?
, I must have deleted the S3 bucket while clearing out some old stacks (the CDK Toolkit stack was still up). Deleted the stack, ran 
CDK_NEW_BOOTSTRAP=true cdk bootstrap
and looks to be resolved
8 Views
Open in Slack
PreviousNext
Powered by