CODEWITHSUNDEEP
pythoncelerydjango-celerycelery-task
anonymous coward
anonymous coward

Reputation: 12824

Is it wrong to just use `T.s([args])` to just call Celery tasks?

The Backstory

In the first part of Celery docs, for "Calling Tasks", they describe using delay() and apply_async(), e.g.: 

task.delay(arg1, arg2, kwarg1='x', kwarg2='y')

task.apply_async(args=[arg1, arg2], kwargs={'kwarg1': 'x', 'kwarg2': 'y'})

They go on to explain:

So delay is clearly convenient, but if you want to set additional execution options you have to use apply_async.

I want the extra options, but passing args/kwargs to apply_async() looks ugly to me.

Instead, I've just been using Task.s() (signatures), because I can pass in the args in a way that reads like a function and just append the call to apply_async().

To explain, this is what most of my tasks look like where I create them: 

task_id = cool_task.s(arg1, arg2).apply_async()

... purely for aesthetics.

The Question

Have I overlooked some downside to calling my tasks this way?

Based on my reading the Celery Canvas docs, I know I'm not using signatures for their potential. But am I doing something wrong, that may bite me later?

Upvotes: 1

Views: 326

Answers (1)

Chillar Anand
Chillar Anand

Reputation: 29594

There is no problem with calling tasks using signatures or partials. However, there are cases where you might pass some arguments to a partial and then pass remaining arguments at a later point.

You should be careful in such scenarios. If you use a partial in a chain with incorrect args, the previous task sends its result to partial and which might not be what you want. In such cases, you can use immutable signatures.

Upvotes: 1

Related Questions