Assigned
Status Update
No update yet.
Comments
su...@google.com
su...@google.com
I also experience a high number of 502 in europe-west1
jo...@gmail.com
We suspect that we may be running into some sort of rate limit. The Cloud Tasks API Quota for maximum requests per minute is rather high (6 million/min) and we're not even close to that, but we believe that when we have bursts of task creation that the API then throws the 502.
j....@googlemail.com
Any update on this? It seems to be happening again. We are experiencing both high latency and 502, the requests are seconds apart.
ja...@celbux.com
The Delete Queue, and Delete Tasks buttons are far too ambiguous. I constantly find myself accidently clicking Delete Queue, and then cancelling. However today, I accidently deleted my queue. And like everyone else, we have a monolith codebase with reference to this queue in multiple different microservices. 7 days for a mistake is appauling. Just queue the Delete Queue request onto a Cron with an ID. And allow this cron to be cancelled within a specified timeframe to cater for mistakes. Should be a dead-simple frontend feature
to...@octue.com
+1000 this is total misery when using terraform or similar tools. Very happy to discuss with teh development team if wanting to knock around ideas for implementation or crystallise a business case for this.
yo...@citibox.com
+1
me...@davie.com
I'm struggling with using the Algolia firebase EXT through my CI/CD pipeline, and thought I would delete some of the queues to start again - I can't believe that I've got to wait 7 days before installing another instance that matches the same queue name :(
ha...@propelle.io
Can this please be looked at. 7 days is absolutely ridiculous, the effect this has on development cycles is atrocious and god knows why it's been implemented in this way
da...@gmail.com
I'm using Terraform and I'm creating and destroying the environment in order to test if my script is working properly. The fact that I have to wait 7 days is really annoying. Even 1 day is too much. What is going on with Cloud Task?
+1
+1
bo...@gohighlevel.com
Is there any update on this?
da...@mobilitydata.org
I just hit this issue. Like some of the commenters here, I'm using automation to deploy services(terraform). The reason for having a predictable naming convention is that references to the queue don't need to have a particular configuration if the code calling it knows which "environment" and a previously agreed name pattern. Convention instead of configuration makes a lot of sense in large deployments to avoid huge configuration effort. So, the cloud task name for me is significant as a reference. Waiting x number of days defeats all the good naming convention/automation design on my side. This also kills one essential principle for cloud development: Experimentation.
I understand the asynchronous nature of the cloud tasks expressed in the documentation:
`
If you delete a queue from the Google Cloud console, you must wait 3 days before recreating it with the same name. This waiting period prevents unexpected behavior in tasks that are executed at the time of deletion or waiting to be executed. It also avoids internal process failures in the delete or recreate cycle.
`
https://cloud.google.com/tasks/docs/deleting-appengine-queues-and-tasks#delete-queues
I'm wondering if just blocking the deletion of the queue when it is not empty will be enough to allow the names to be reusable. Yes, it might be the case that a code from the internal lifecycle(I'm not sure what was referred to here in the documentation), but this is probably an edge case that should not take priority over the reasons mentioned before.
TLDR: +1
I understand the asynchronous nature of the cloud tasks expressed in the documentation:
`
If you delete a queue from the Google Cloud console, you must wait 3 days before recreating it with the same name. This waiting period prevents unexpected behavior in tasks that are executed at the time of deletion or waiting to be executed. It also avoids internal process failures in the delete or recreate cycle.
`
I'm wondering if just blocking the deletion of the queue when it is not empty will be enough to allow the names to be reusable. Yes, it might be the case that a code from the internal lifecycle(I'm not sure what was referred to here in the documentation), but this is probably an edge case that should not take priority over the reasons mentioned before.
TLDR: +1
ro...@onr.org.br
+1
Description
What you would like to accomplish:
Users would like to be able to restore a Cloud Tasks queue when it is mistakenly deleted instead of having to wait the 7 day period mentioned in the documentation [1].
How this might work:
The Cloud Task queue would remain in a temporary state with an option to restore it within a certain time interval. As a suggestion, this option could be available for the 3 days after the deletion was made as it would allow undesired deletes to be reversed.
If applicable, reasons why alternative solutions are not sufficient:
As of now, there is no method to restore the Cloud Task queue if one is mistakenly deleted besides the creation of a new queue with a different name before the 7 day waiting time.
Other information: [1]:https://cloud.google.com/tasks/docs/deleting-appengine-queues-and-tasks#deleting_queues