Unexpected behavior in regards to transaction handling [django]

[ticosax]

Hi,
Considering this snippet of a more or less realistic django project

@task()
@transaction.atomic()
def outer() -> None:
    MyModel.objects.filter(name="outer").exists()

    inner.defer()
    raise ValueError


@task()
@transaction.atomic()
def inner() -> None:
    MyModel.objects.filter(name="inner").exists()

To my surprise, inner() task was published into the queue (and executed).
Instead I would have expected the transaction to be rollback-ed and the task wouldn't exists afterwards.
The explicit @transaction.atomic() wrapping is being defeated here.

Is it the expected behavior of procrastinate ?
How can I guarantee that tasks are published within explicit transactional boundaries ?

[medihack]

Hi @ticosax, tasks are processed completely independently from one another (in case of synchronous tasks, even in different threads). This is still true when deferring a task from inside another task. So, in your example, the job of the inner task is put on the queue and still exists there even after the error is raised. You can cancel it actively, but unfortunately, Procrastinate won't handle that for you.

[ticosax]

I feel unsatisfied with your answer, let me explain why:
I'm not expecting procrastinate to handle the cancellation for me, instead I'm expected procrastinate to honor transactional semantics. aka the rollback should cancel the task, not procrastinate.
I should specify my question: what expectation I can make in regards to transaction semantics ?
My thinking is, If it's wrapped in transaction.atomic(), then it should be transactional since I 'm using the same connection to the same database, no ?

[ticosax]

I have another use case that doesn't involve cancellation, but also exhibit same symptoms.

@task()
@transaction.atomic()
def creation() -> None:
    model = MyModel.objects.create(name="outer")

    after_create.defer(pk=model.pk)
    # continue working slowly
    # ...


@task()
@transaction.atomic()
def after_create(pk: int) -> None:
   model = MyModel.objects.get(pk=pk)  # might raise MyModel.DoesNotExist
   # do some work
   # ...

In the absence of transactional boundaries, after_create can be executed before the transaction of creation is committed.
It means that loading the model with the pk in after_create will fail as it is not yet visible to the worker thread.

[medihack]

I feel unsatisfied with your answer, let me explain why: I'm not expecting procrastinate to handle the cancellation for me, instead I'm expected procrastinate to honor transactional semantics. aka the rollback should cancel the task, not procrastinate. I should specify my question: what expectation I can make in regards to transaction semantics ? My thinking is, If it's wrapped in transaction.atomic(), then it should be transactional since I 'm using the same connection to the same database, no ?

Ah, ok, now I see the problem. We don't use Django connections for the worker that processes the tasks, but I am not sure about the defer inside the tasks that are processed by a worker. I have to think about this (and see if there is some easy solution).

[medihack]

Unfortunately, I didn't find an explanation why inner.defer isn't rolled back. It even seems that it uses a Django connection (but obviously another one). I will hopefully find some time to investigate that further, but unfortunately not in the short term 😞. Please let me know if you find a way or if you have more clues about what's happening here (maybe some specific Django stuff?!).
A workaround could be something like this:

@task()
@transaction.atomic()
def outer() -> None:
  MyModel.objects.filter(name="outer").exists()
  transaction.on_commit(lambda: inner.defer())
  raise ValueError
``´

[ticosax]

Thanks for looking into it. I'll have a look.

[ticosax]

I've made some progress, (conceptually), on how to approach this.
It seems that only the defer action should be handled by the django connection, instead of being delegated to the procrastinate one. Do you think it's a valid direction worth pursuing?

[ewjoachim]

That's an interesting idea. This way, no need to handle a connection or anything, we just use Django's way of doing everything.