Custom handler url?

[aaajeetee]

This package is very nice, and I use it with great pleasure. However, I got to ask: why is the handler url always fixed at /handle-task? Personally, I would like to be able to overwrite this with my own handle-task endpoint, pass additional query-parameters etcetera. Also, I would like to have a different handler for different jobs. As of now, I'm forced to overwrite the config value, which doesn't quite feel right.

I'm happy to make a pull request with a change for this. Perhaps by checking if a method exists on the job and call that method? And fall back to /handle-task, to make it backwards compatible.

I'm wondering if there is a specific reason for this not to be adjustable, and if you'd be willing to look into (and merge) such a feature?

[Plytas]

I'd like to see ability to specify url per queue too. We're actually running a fork because of this reason. It was my colleague that implemented this so I'm not yet familiar with how we do it, but I'd be willing to investigate and help contribute.

[marickvantuil]

This package is very nice, and I use it with great pleasure

Thanks!

I'm open to all ideas, and I'm interested to know: What is the reasoning for having different endpoints for jobs? Is it, so a job can be dispatched on app A, but be handled by app B? Some examples/use-cases would help!

pass additional query-parameters

Some examples would help here too. I'm currently working on 4.x which has a configurable /handle-task route name, but it's app specific, not job specific. 4.x will also make it possible to add additional headers which can be accepted in the job:

use Illuminate\Queue\Queue;

Queue::connection()->setTaskHeaders(fn (array $job) => [
    'X-My-Header' => $job['displayName']
]);

Would that solve that problem?

Anyway, love to hear more. Thanks!

[Plytas]

Using different routes per queue lets us route tasks to differently sized containers. Some tasks are simple and fast so they don't need as much processing power as others. This lets us save on costs too.

Another benefit is being able to query our logs by request url to see logs from a specific queue.

[aaajeetee]

Basically exactly the same 2 use cases that @Plytas mentions, I'm having as well.

A configurable /handle-task route is a big improvement, but I'd like to extend that idea by having it configurable per job - like having a "handlerUrl()" method available on the job for example.

As I said, I'm more than happy to contribute or help in some way, but I didn't want to 'push' it without consulting first.

[marickvantuil]

Sounds like a great idea. Feel free to make a PR with the changes. Can you please make them against the 4.x-dev branch? I've tidied up the code base quite a bit in 4.x so that should also make it easier to make this change. I'll release it when the rest of 4.x is done too, which will take hopefully no more than a few more weeks.

Thinking of it, if we're doing this on a by-job basis, it might make more sense to have the headers also be a by-job basis... Something like:

class ProcessPodcast implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public $tries = 3;

    public function handle()
    {
        // ...
    }
    
    public function taskHandlerUrl(): string
    {
        // ...
    }
    
    public function taskHeaders(): array
    {
        return [
            'X-My-Header' => 'My-Value',
        ];
    }
}

Doing it through the queue.php config file might also be an option. Keeping these sorts of configurations together. Also, more flexible if there is a test/staging environment.

'cloudtasks' => [
    'handler'               => env('STACKKIT_CLOUD_TASKS_HANDLER', ''),
    'service_account_email' => env('STACKKIT_CLOUD_TASKS_SERVICE_EMAIL', ''),
    'signed_audience'       => env('STACKKIT_CLOUD_TASKS_SIGNED_AUDIENCE', true),
    // The default handler
    'handler'               => env('STACKKIT_CLOUD_TASKS_HANDLER'),
    // Queue specific handlers
    'queue_handlers'        => [
      'low_performance' => env('STACKKIT_CLOUD_TASKS_LOW_PERF_HANDLER', env('STACKKIT_CLOUD_TASKS_HANDLER')),
      'high_performance' => env('STACKKIT_CLOUD_TASKS_HIGH_PERF_HANDLER', env('STACKKIT_CLOUD_TASKS_HANDLER')),
    ]
],

ResourceHeavyJob::dispatch()->onQueue('high_performance');

[aaajeetee]

Yeah something like that sounds good. Support config options and have the option to overwrite it per task. Personally I would like to add 2 interfaces for that; one for the taskHandlerUrl() method and 1 for the taskHeaders() method.

I'll try to write some code for this this week, can't make any promises though 😛

Update: I did manage to implement something, I created a PR: #139
I think any feedback on the code can best be placed there.

Since there is a PR, I'm not sure if this discussion can be closed or not?