Can't control rate limit on Google Cloud Tasks API - google-cloud-tasks

Question

I'm trying to rate limit Google Cloud Tasks to no more than 1 processed task per second.
I've created my queue with:
gcloud tasks queues create my-queue \
--max-dispatches-per-second=1 \
--max-concurrent-dispatches=1 \
--max-attempts=2 \
--min-backoff=60s
Describing it gives me:
name: projects/my-project/locations/us-central1/queues/my-queue
rateLimits:
maxBurstSize: 10
maxConcurrentDispatches: 1
maxDispatchesPerSecond: 1.0
retryConfig:
maxAttempts: 2
maxBackoff: 3600s
maxDoublings: 16
minBackoff: 60s
state: RUNNING
After creating a bunch of tasks I can see in the logs that many of them are undesirably being processed in the time period of 1 second:
2019-07-27 02:37:48 default[20190727t043306] Received task with payload: {'id': 51}
2019-07-27 02:37:48 default[20190727t043306] "POST /my_handler HTTP/1.1" 200
2019-07-27 02:37:49 default[20190727t043306] Received task with payload: {'id': 52}
2019-07-27 02:37:49 default[20190727t043306] "POST /my_handler HTTP/1.1" 200
2019-07-27 02:37:49 default[20190727t043306] Received task with payload: {'id': 53}
2019-07-27 02:37:49 default[20190727t043306] "POST /my_handler HTTP/1.1" 200
2019-07-27 02:37:49 default[20190727t043306] Received task with payload: {'id': 54}
2019-07-27 02:37:49 default[20190727t043306] "POST /my_handler HTTP/1.1" 200
2019-07-27 02:37:49 default[20190727t043306] Received task with payload: {'id': 55}
2019-07-27 02:37:49 default[20190727t043306] "POST /my_handler HTTP/1.1" 200
2019-07-27 02:37:49 default[20190727t043306] Received task with payload: {'id': 56}
2019-07-27 02:37:49 default[20190727t043306] "POST /my_handler HTTP/1.1" 200
2019-07-27 02:37:49 default[20190727t043306] Received task with payload: {'id': 57}
2019-07-27 02:37:49 default[20190727t043306] "POST /my_handler HTTP/1.1" 200
2019-07-27 02:37:49 default[20190727t043306] Received task with payload: {'id': 58}
How do I properly enforce it to run no more than 1 task during this 1 second time interval?
Update 30/06:
I've tried it again with a basic setup, same issue.
More details on setup and process:
Source code https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/flexible/tasks, no modifications
Deploy app.yaml, not app.flexible.yaml
Trigger a task several times: python create_app_engine_queue_task.py --project=$PROJECT_ID --queue=$QUEUE_ID --location=$LOCATION_ID --payload=hello
Check logs: gcloud app logs read
This time they took a while to start processing, but after that it seems they were all processed more or less simultaneously:
Full logs:
2019-07-30 00:22:37 default[20190730t021951] [2019-07-30 00:22:37 +0000] [9] [INFO] Starting gunicorn 19.9.0
2019-07-30 00:22:37 default[20190730t021951] [2019-07-30 00:22:37 +0000] [9] [INFO] Listening at: http://0.0.0.0:8081 (9)
2019-07-30 00:22:37 default[20190730t021951] [2019-07-30 00:22:37 +0000] [9] [INFO] Using worker: threads
2019-07-30 00:22:37 default[20190730t021951] [2019-07-30 00:22:37 +0000] [23] [INFO] Booting worker with pid: 23
2019-07-30 00:22:37 default[20190730t021951] [2019-07-30 00:22:37 +0000] [26] [INFO] Booting worker with pid: 26
2019-07-30 00:27:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:27:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:27:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:27:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:27:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:27:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:41 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:41 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:42 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:42 default[20190730t021951] Received task with payload: hello
2019-07-30 00:37:43 default[20190730t021951] "POST /example_task_handler HTTP/1.1" 200
2019-07-30 00:37:43 default[20190730t021951] Received task with payload: hello

Answer 1

tl;dr  It's probably working as intended.  You can expect an initial burst of maxBurstSize tasks which then slows down to maxDispatchesPerSecond.
The reason for this is the "token bucket" algorithm: there's a bucket which can hold at most maxBurstSize tokens, and initially has that many tokens in it.  A task is dispatched if it's scheduled time has arrived AND there's a token in the bucket AND fewer than maxConcurrentDispatches are in flight, otherwise we wait for those conditions to be met.  When a task is dispatched, a token is removed from the bucket.  When the bucket is not full, tokens are added at a rate of maxDispatchesPerSecond.
So the rate isn't precisely a limit on task dispatch.  Tasks can be sent at an arbitrary rate as long as there are tokens in the bucket and tasks ready to run.  Only when tasks have to wait for tokens do we have to slow down to the given rate.  Since the bucket starts full you can get an initial burst.
In the Cloud Tasks API and console the bucket size is read only (and the API calls it max_burst_size).  But using the older queue.yaml configuration you can control bucket size along with the other parameters, e.g.
queue:
- name: my-appengine-queue
  rate: 2/s
  bucket_size: 20
  max_concurrent_requests: 5
Then gcloud app deploy queue.yaml.  If you do that however, be aware of these pitfalls: https://cloud.google.com/tasks/docs/queue-yaml#pitfalls
FYI there's an issue open to see if docs can be improved.

Answer 2

The queues created using queue.yaml and the queues created by Cloud Tasks - however you do it - are the same queues. There are, however, issues that can arise if you mix using queue.yaml and Cloud Tasks Queue Management methods. See https://cloud.google.com/tasks/docs/queue-yaml for more information.