stackkit/laravel-google-cloud-tasks-queue

Task name generation

gaborbencebekesi opened this issue · 4 comments

In version 3.X the retry logic is the Laravel built-in solution.

After upgrading to 3.5.0 I faced to the following problem.

  • Job was created and sent to the Cloud Tasks.
  • Laravel handler was called but job processing failed (due to application error).
  • When the new (retry) job was constructed, the task name was unchanged. However, sending it Cloud Task failed because a queue cannot contain two tasks with the same name in a short period of time.

As a result, the job failed then disappeared.

Google\ApiCore\ApiException

{
    "message": "The task cannot be created because a task with this name existed too recently. For more information about task de-duplication see https:\/\/cloud.google.com\/tasks\/docs\/reference\/rest\/v2\/projects.locations.queues.tasks\/create#body.request_body.FIELDS.task.",
    "code": 6,
    "status": "ALREADY_EXISTS",
    "details": []
}

I created a small patch, and it works perfectly.

diff --git a/src/CloudTasksQueue.php b/src/CloudTasksQueue.php
index c066687..2cda3d4 100644
--- a/src/CloudTasksQueue.php
+++ b/src/CloudTasksQueue.php
@@ -197,7 +197,7 @@ class CloudTasksQueue extends LaravelQueue implements QueueContract
             $this->config['project'],
             $this->config['location'],
             $queueName,
-            $displayName . '-' . $payload['uuid']
+            $displayName . '-' . $payload['uuid'] . '-' . ($payload['internal']['attempts'] ?? 0)
         );
     }

Thanks, will check this later!

i386 commented

Also seen this live in production. I think it might be more prudent to append a timestamp?

OK, I created a Pull Request. I added a timestamp at the end (because it seems more unique), but I'm questioning if adding the attempt number is better (because it's also unique + it prevents duplicate creation of the same attempt - if that ever happens).

Curious to know other opinions so I'll wait for a bit and maybe merge it by Friday otherwise. Thanks!

Should be fixed in v3.5.1!