Assigned
Status Update
No update yet.
Comments
em...@google.com
I also experience a high number of 502 in europe-west1
he...@herospace.app
Comment has been deleted.
ay...@joinvitalhealth.com
Any update on this? It seems to be happening again. We are experiencing both high latency and 502, the requests are seconds apart.
sa...@ingka.com
Hey Guys,
Do we have any update on this ??
Even I looking forward for such feature
Do we have any update on this ??
Even I looking forward for such feature
lo...@gmail.com
Hi,
We have found that in by and large, shcedules are monthly so extending this limit by 60 days instead of 30 days will solve most part of the problem.
30 days limit is too stringent as number of days in a calendar month may vary from 28 to 31 leaving a significant scope of missed schedules.
Hope GCP team listens to it and act upon soon.
We have found that in by and large, shcedules are monthly so extending this limit by 60 days instead of 30 days will solve most part of the problem.
30 days limit is too stringent as number of days in a calendar month may vary from 28 to 31 leaving a significant scope of missed schedules.
Hope GCP team listens to it and act upon soon.
la...@gmail.com
Hey! Would love to see this implemented, I am creating an experience marketplace where payment is paid upfront to our marketplace but has to be paid to experience providers far out in the future once the experience has been provided, could be years in the future. Would love to know if this is being worked on, even if it means slight additional costs for storage :)
ja...@freiheit.com
Hey there :)
I want to +1 this feature request and give another point of view.
--- First argument: Make users life significantly easier
Clearly, there are many use cases for tasks more than 30days in the future.
And Cloud Tasks indirectly already supports this:https://dev.to/mailmeteor/how-to-schedule-tasks-in-more-than-30-days-in-google-cloud-tasks-api-35f
It "just" requires a middleware that keeps re-scheduling your task until you get to the date.
There are two issues I see with this:
1. It's extra work that every user has to implement, when it would (seem to) be minimal to no extra work to have a (much) higher quota.
2. The user now needs to worry about whether his middleware implementation still guarantees everything that Cloud Tasks guarantees (notably Deduplication).
--- Second argument: The current implementation does not save cost
The argument for the quota seems to be that keeping the tasks around longer costs more storage:https://stackoverflow.com/questions/58530361/how-increase-maximum-schedule-time-in-gcloud-tasks-api#comment103417942_58544657
But since there is a workaround with a middleware, this argument quickly falls apart.
Clearly, when a user implements the middleware trick, the quota has not lead to any storage usage reduction at all (depending on the implementation, it might even have increased it).
And the middleware requires extra implementation effort and (potentially significantly more) network calls.
This even makes it hard to estimate the cost (despite the simple cost model).
--- Conclusion: Support it and charge for it
As a Cloud Task user, I want to be able to schedule tasks beyond 30 days without extra effort, and transparently see what costs this may cause.
This can be solved by allowing to increase the "Max task retention" and "Maximum schedule time for a task" quota (per queue), and a simple addition to the cost model: cost / million tasks stored over 30 days (without execution).
I want to +1 this feature request and give another point of view.
--- First argument: Make users life significantly easier
Clearly, there are many use cases for tasks more than 30days in the future.
And Cloud Tasks indirectly already supports this:
It "just" requires a middleware that keeps re-scheduling your task until you get to the date.
There are two issues I see with this:
1. It's extra work that every user has to implement, when it would (seem to) be minimal to no extra work to have a (much) higher quota.
2. The user now needs to worry about whether his middleware implementation still guarantees everything that Cloud Tasks guarantees (notably Deduplication).
--- Second argument: The current implementation does not save cost
The argument for the quota seems to be that keeping the tasks around longer costs more storage:
But since there is a workaround with a middleware, this argument quickly falls apart.
Clearly, when a user implements the middleware trick, the quota has not lead to any storage usage reduction at all (depending on the implementation, it might even have increased it).
And the middleware requires extra implementation effort and (potentially significantly more) network calls.
This even makes it hard to estimate the cost (despite the simple cost model).
--- Conclusion: Support it and charge for it
As a Cloud Task user, I want to be able to schedule tasks beyond 30 days without extra effort, and transparently see what costs this may cause.
This can be solved by allowing to increase the "Max task retention" and "Maximum schedule time for a task" quota (per queue), and a simple addition to the cost model: cost / million tasks stored over 30 days (without execution).
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 have a subscription system and we would like to schedule an expiration alert. However the longest plan is 1 year long. Thus we would need to schedule a task 11 months in the future.
How this might work:
On subscription time we set the scheduled time of the task 11 months in the future.
If applicable, reasons why alternative solutions are not sufficient:
The alternative is to use our own scheduler to launch tasks the day those tasks expire. However it is another system to maintain and develop for us
Other information (workarounds you have tried, documentation consulted, etc):