#celery

i wasnt specifying a 2 arguements in my @worker_init.connect() method

im working.

I'm attempting to use a group to execute a stack of subtasks. I don't seem to be able to get a task id for this: a group doesn't have an AsyncResult object?

Ah, I think I was not looking at the result, just the group instance...

Hi everybody, could you participate in my poll please? https://docs.google.com/forms/d/1PrANyWrFzDd8dS...

Is there anyway to access/read a task's kwargs after the task has run? I have a task which was set with an eta and it ran, but it ran on behalf of the wrong user (user_id was passed as a kwarg) and I need to work out where the problem is....

I have the task's ID obviously

anyone have any thoughts on reading a task's kwargs after the task has run?

georgeirwin, there is task_postrun signal, but it is defined on a worker side, I don't know is it ok for you

thanks malinoff - useful for debugging, but the task has already run, so the postrun signal won't help me now sadly... I'm guessing that what I'm asking isn't possible

unless rabbitmq stores the kwargs in some way

georgeirwin, you said you need to inspect a task's kwargs after the task has run

task_postrun signal allows you to do that

ah, i think i got it. You have already executed task and you want to inspect it's kwargs, right?

malinoff: yes, but I need to setup that signal before I run the task? There was a specific error with a task which has already run, but I didn't have task_postrun setup

yes

What result backend you used for that task?

rabbitmq

ampq://

Did you call result.get() ?

or task.apply_async().get()

or similar to

task.apply_async(kwargs={....})

georgeirwin, you can try to inspect rabbitmq if it still has the task result

maybe it has not been acked

malinoff: what's the best way to do that?

app.backend.get_task_meta(task_id)

it should return the task payload

the result payload, i meant

great, thanks malinoff - I'll try that

if it returns {'status': states.PENDING, 'result': None}, i think you can say goodbye to that result :(

malinoff: {'status': 'SUCCESS', 'traceback': None, 'result': True, 'task_id': '7a4e43c9-274e-49fa-8665-066c265b8044', 'children': []}

cool! so the backend still holds the result

uhm, but without kwargs

yup - I'm not sure how I can access the kwargs values...... ?

Well, I have no idea how you can get that, really

can't you just run that task again?

and use task_postrun signal?

I suppose I could - I don't particularly want the outcome to happen again, but it's not a big issue! Is there any way to trigger the task with the postrun signal from the command line (i.e. without changing the actual code?)

don't think so - because tasks are executed remotely, so your remote machine is changing kwargs, not the caller machine

ok, thanks malinoff

georgeirwin, another option you have is to execute the task locally, since if kwargs are changed, the task code should change them

just by calling task(kwargs={...}), or task.apply(kwargs={...})

malinoff: true. To get to the root of the question - is there any way in which a task which is called with an eta can have its kwargs altered after it is called, but before it is run?

The issue was that a task was set to run at a specific time (task.apply_async(eta=datetime)) and one kwarg is the ID of the User for whom the task should run. The task ran at the correct time, but for the wrong user

I don't know - but it shouldn't, of course

did you change kwargs dict after task.apply_async ?

I thought not.... I'll look elsewhere then before investigating that option. No - didn't update the kwargs after apply_async

so it's pretty strange

If you're not very familiar with Celery internals, when you call task.apply_async, celery serializes task name, args, kwargs and other necessary information and sends it as a string to the broker

worker takes that string from the broker, deserializes it and executes the task

So even if you changed kwargs after apply_async, kwargs shouldn't change since it has been serialized

You should definitely write a dumb "black box" task with the same input and output, but without doing something actually and test it with the same kwargs

malinoff: I had understood that's what happened, but I don't have enough experience of celery to rule out the kwargs being corrupted somehow. It's odd as the user id comes from Django's request object, so it must be something in my code which is wrong... Either that or the user who intended the task to run logged in as me!

georgeirwin, yeah, you should print kwargs before calling the task :)

will do, thanks malinoff

Will a "group" be killed by time limits, or only it's subtasks?

If starting more than one worker, does celeryd_init fire once or once for each worker?