Assigned
Status Update
No update yet.
Comments
ni...@google.com
I also experience a high number of 502 in europe-west1
mi...@nurturecloud.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.
is...@google.com
ta...@mrk.co
Any update on this? It seems to be happening again. We are experiencing both high latency and 502, the requests are seconds apart.
kl...@snapchat.com
I'm looking at this as a blocker to migration as well. Although we can leverage the legacy GAE apps in Python, I'd love to be able to access this as a first class concern.
su...@google.com
su...@google.com
Hello,
Thank you for reaching out to us!
Unfortunately there are no updates as the product team. Will check with the product team and will keep updated about the status of this here. However, please note that there is currently no ETA for this fix.
Thank you for your trust and continued support to improve Google Cloud Platform products.
Description
Please describe your requested enhancement. Good feature requests will solve common problems or enable new use cases.
What you would like to accomplish:
We wish to move from taskqueues to cloud tasks but the fact that we rely heavily on transactional enqueuing is blocking us. The cloud tasks api does not provide any method for enqueuing tasks based on the datastore transaction success/
How this might work:
Not sure how this worked with taskqueue but a similar implementation might work.
If applicable, reasons why alternative solutions are not sufficient:
There do not seem be any public alternatives for transactional enqueueing, unfortunately.
Other information (workarounds you have tried, documentation consulted, etc):
i) Using call_on_commit to enqueue tasks. This is unreliable since we would lose all the tasks if the instance were to die before the call_on_commit was triggered after a successful commit.
ii) We currently write the tasks to datastore as part of the transaction and later enqueue a task to run the tasks from datastore. This works fine but the delay in the task being added to datastore and it being actually run is critical for us (e.g. forgot password flow, we wouldnt want user to wait 30m before getting an email(task to be queued))