Assigned
Status Update
No update yet.
Comments
rw...@google.com
I also experience a high number of 502 in europe-west1
da...@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.
Description
1. Having to expose a public endpoint for HTTP Target tasks, and then having to set up authentication for those task requests.
2. Not being able to best-effort attempt task execution in the same process that scheduled the task. This would be very useful in situations where one triggers a task as a result of a user's HTTP request and wants to send the task result in the HTTP response (but still want to retry the task if the HTTP connection is broken).
Currently, you have to resort to workarounds like polling a shared state (e.g. a DB or shared application cluster state), to see the task result.
Both of these issues could be solved by offering a bidirectional streaming gRPC API to Cloud Tasks. Tasks could be scheduled by the client using the client->server stream, and execution requests could be sent on the server->client stream which would allow for the scheduler-executor affinity. Since the client initiates the API call, no public endpoint is needed.