https://serverless-stack.com/ logo
Join Slack
Powered by
I could still really use a guide on what to do whe...
# help
a
I could still really use a guide on what to do when deployment fails for specific reasons. I tried to add 
fifo: true
config to an sqs queue, and now it can't deploy my project anymore. It tries to update the queue, but then it says
Copy code
dev3-convento-cron | UPDATE_ROLLBACK_IN_PROGRESS | AWS::CloudFormation::Stack | dev3-convento-cron | Export dev3-convento-cron:ExportsOutputRefReminderMailQueue696E8B23D1985592 cannot be updated as it is in use by dev3-convento-api
and at the end it says:
Copy code
Stack prod-convento-cron
  Status: failed
  Error: Export prod-convento-cron:ExportsOutputFnGetAttReminderMailQueue696E8B23Arn31F9752B cannot be updated as it is in use by prod-convento-api
I'd like to understand why this happens, how to prevent it, and how to recover from it when it still happens
b
does that queue already exist? you cant change queues from fifo to not fifo or vice versa. you have to delete them and then recreate them
also fifo queues names have to end in .fifo
a
so I have to just remove that stack I guess and then deploy it again?
b
for this case, probably
a
isn't that something the framework should be capable to do itself, though?
or is it a CDK limitation maybe?
b
maybe the framework, but def not cloudformation
a
can't remove it, because it's used by api
eh, i'll just ignore it for now and see how much it will cost me
r
It’s probably the case that the queue has to be replaced to turn it into a fifo queue and it has references that Cloudformation can’t sort out. When I’ve encountered this kind of thing myself I’ve typically commented out the queue and the resources that depend on it, deploy, then uncomment and deploy again with the new config
a
yeah, it's too unwieldy to do this for a prod environment
r
true
@Frank has helped me out with this kind of thing before, he might have some ideas
Maybe you could add the new queue, alongside the existing one, deploy. Then point the consumers to the new one and deploy again
a
nah, it's ok, I'll just leave it as it is for the moment
but thanks for the suggestions
f
@Adrian Schweizer what’s going on here is that the Reminder Mail Queue is being referenced from another stack, ur API stack. Behind the scene, the Queue’s ARN is exported from the cron stack, and imported by the api stack.
And when u update the FIFO setting, CloudFormation deletes the existing queue and create a new queue with fifo enabled. ^Note that it is not possible to simply enable FIFO on an existing queue.
This causes the Queue’s ARN to change, and in turn the exported value also changes.
CloudFormation has a limitation that if an exported value is in use (ie. imported by the api stack), it cannot be update. Hence the error you are getting.
The work around @Ross Coundon suggested is actually the best way to go about this. It’s a 2 deploy process: 1. add a new queue + deploy 2. remove the old queue + deploy
Let me know if that makes sense.
a
@Frank yeah, thanks, that actually worked well
3 Views
Open in Slack
PreviousNext
Powered by