You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
java --version
openjdk 17.0.5 2022-10-18
OpenJDK Runtime Environment Temurin-17.0.5+8 (build 17.0.5+8)
OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (build 17.0.5+8, mixed mode)
[REQUIRED] Test case
The minimal example is whatever minimal example can be derived from the Firebase docs, see reproduction steps below. For the enqueue call, include the scheduleDelaySeconds parameter:
I'm not including an uri in the second parameter object here because it causes issues in my emulator environment, and this bug report is about the emulator.
Enqueue a task in the emulator with scheduleDelaySeconds > 0, in my example, 40 seconds.
Observe that scheduleDelaySeconds has no effect, as soon as the task is enqueued, it is executed virtually without delay. See debug logs below.
[REQUIRED] Expected behavior
scheduleDelaySeconds should be respected as it behaves that way in deployed Firebase environments, and I don't see why the behavior should be different in local emulators.
If Emulator users want to manually invoke their schedules tasks more quickly in local testing, they can use the REST API designed for that.
I'd also like to quote from another Firebase user with same issue (3 weeks ago):
Is a solution to this coming? Scheduling is the reason I'm using Cloud Tasks in the first place :)
Scheduling is also the main reason why I want to use Cloud Tasks. It's why I'm opening a new issue here to raise attention to this, since #4884 is closed, and I think this is still a bug.
[REQUIRED] Actual behavior
The issue was already observed in #4884 but apparently never addressed:
[...]
The task will run immediately and not respect scheduleTime or scheduleDelaySeconds should you have one set.
[...]
In my own testing, I could confirm that scheduleDelaySeconds was not respected.
It is interesting that retryConfig.minBackoffSeconds in the queue setup is respected however.
Debug logs
I don't want to drop my full real application logs here, because I can't easily scan it for potentially sensitive data, but I'll try to extract relevant bits:
My queue handler method and exported onTaskDispatched return value are both called checkContactCreation.
[2025-02-25T16:48:06.511Z] addTaskQueueTrigger {"retryConfig":{"maxAttempts":15,"maxRetrySeconds":null,"maxBackoffSeconds":null,"maxDoublings":null,"minBackoffSeconds":60},"rateLimits":{"maxConcurrentDispatches":6,"maxDispatchesPerSecond":null}}
[2025-02-25T16:48:06.511Z] >>> [apiv2][query] POST http://127.0.0.1:9499/projects/demo-test/locations/europe-west1/queues/checkContactCreation [none]
[2025-02-25T16:48:06.511Z] >>> [apiv2][body] POST http://127.0.0.1:9499/projects/demo-test/locations/europe-west1/queues/checkContactCreation {"retryConfig":{"maxAttempts":15,"maxRetrySeconds":null,"maxBackoffSeconds":null,"maxDoublings":null,"minBackoffSeconds":60},"rateLimits":{"maxConcurrentDispatches":6,"maxDispatchesPerSecond":null},"defaultUri":"http://127.0.0.1:5001/demo-test/europe-west1/checkContactCreation"}
✔ tasks: Created queue with key: queue:demo-test-europe-west1-checkContactCreation {"metadata":{"emulator":{"name":"tasks"},"message":"Created queue with key: queue:demo-test-europe-west1-checkContactCreation"}}
[2025-02-25T16:48:06.519Z] Created task queue queue:demo-test-europe-west1-checkContactCreation with configuration: {"retryConfig":{"maxAttempts":15,"maxRetrySeconds":null,"maxBackoffSeconds":3600,"maxDoublings":16,"minBackoffSeconds":60},"rateLimits":{"maxConcurrentDispatches":6,"maxDispatchesPerSecond":500},"timeoutSeconds":10,"retry":false,"defaultUri":"http://127.0.0.1:5001/demo-test/europe-west1/checkContactCreation"} {"metadata":{"emulator":{"name":"tasks"},"message":"Created task queue queue:demo-test-europe-west1-checkContactCreation with configuration: {\"retryConfig\":{\"maxAttempts\":15,\"maxRetrySeconds\":null,\"maxBackoffSeconds\":3600,\"maxDoublings\":16,\"minBackoffSeconds\":60},\"rateLimits\":{\"maxConcurrentDispatches\":6,\"maxDispatchesPerSecond\":500},\"timeoutSeconds\":10,\"retry\":false,\"defaultUri\":\"http://127.0.0.1:5001/demo-test/europe-west1/checkContactCreation\"}"}}
[2025-02-25T16:48:06.521Z] <<< [apiv2][status] POST http://127.0.0.1:9499/projects/demo-test/locations/europe-west1/queues/checkContactCreation 200
[2025-02-25T16:48:06.521Z] <<< [apiv2][body] POST http://127.0.0.1:9499/projects/demo-test/locations/europe-west1/queues/checkContactCreation {"taskQueueConfig":{"retryConfig":{"maxAttempts":15,"maxRetrySeconds":null,"maxBackoffSeconds":3600,"maxDoublings":16,"minBackoffSeconds":60},"rateLimits":{"maxConcurrentDispatches":6,"maxDispatchesPerSecond":500},"timeoutSeconds":10,"retry":false,"defaultUri":"http://127.0.0.1:5001/demo-test/europe-west1/checkContactCreation"}}
✔ functions[europe-west1-checkContactCreation]: http function initialized (http://127.0.0.1:5001/demo-test/europe-west1/checkContactCreation). {"metadata":{"emulator":{"name":"functions"},"message":"http function initialized (http://127.0.0.1:5001/demo-test/europe-west1/checkContactCreation)."}}
[2025-02-25T16:48:06.521Z] addTaskQueueTrigger {"retryConfig":{"maxAttempts":1,"maxRetrySeconds":null,"maxBackoffSeconds":null,"maxDoublings":null,"minBackoffSeconds":null},"rateLimits":{"maxConcurrentDispatches":null,"maxDispatchesPerSecond":null}}
When an enqueue happens:
⚠ Google API requested!
- URL: "https://oauth2.googleapis.com/token"
- Be careful, this may be a production service. {"metadata":{"emulator":{"name":"functions"},"function":{"name":"europe-west1-onUserPrivateWriteV2"},"extension":{},"message":"Google API requested!\n - URL: \"https://oauth2.googleapis.com/token\"\n - Be careful, this may be a production service."}}
[2025-02-25T16:48:13.213Z] Enqueueing task /projects/demo-test/locations/europe-west1/queues/checkContactCreation/tasks/1815625063765355 onto queue:demo-test-europe-west1-checkContactCreation {"metadata":{"emulator":{"name":"tasks"},"message":"Enqueueing task /projects/demo-test/locations/europe-west1/queues/checkContactCreation/tasks/1815625063765355 onto queue:demo-test-europe-west1-checkContactCreation"}}
[REQUIRED] Environment info
firebase-tools: 13.31.2
Platform: macOS
Since the emulator uses java:
[REQUIRED] Test case
The minimal example is whatever minimal example can be derived from the Firebase docs, see reproduction steps below. For the enqueue call, include the
scheduleDelaySeconds
parameter:I'm not including an
uri
in the second parameter object here because it causes issues in my emulator environment, and this bug report is about the emulator.[REQUIRED] Steps to reproduce
scheduleDelaySeconds
> 0, in my example, 40 seconds.scheduleDelaySeconds
has no effect, as soon as the task is enqueued, it is executed virtually without delay. See debug logs below.[REQUIRED] Expected behavior
scheduleDelaySeconds
should be respected as it behaves that way in deployed Firebase environments, and I don't see why the behavior should be different in local emulators.If Emulator users want to manually invoke their schedules tasks more quickly in local testing, they can use the REST API designed for that.
I'd also like to quote from another Firebase user with same issue (3 weeks ago):
Originally posted by @starcrest in #4884
Scheduling is also the main reason why I want to use Cloud Tasks. It's why I'm opening a new issue here to raise attention to this, since #4884 is closed, and I think this is still a bug.
[REQUIRED] Actual behavior
The issue was already observed in #4884 but apparently never addressed:
Originally posted by @tzappia in #4884
In my own testing, I could confirm that
scheduleDelaySeconds
was not respected.It is interesting that
retryConfig.minBackoffSeconds
in the queue setup is respected however.Debug logs
I don't want to drop my full real application logs here, because I can't easily scan it for potentially sensitive data, but I'll try to extract relevant bits:In the logs above, notice the difference between the timestamps of the first enqueue, and the first log from the handler:
They should be at least 40 second apart, but they are ~1.7 seconds apart here.
The text was updated successfully, but these errors were encountered: