Kai Schlamp
Kai Schlamp
> > After thinking about it even more, I will implement a middleware that [wraps the `worker._process_job`](https://github.com/procrastinate-org/procrastinate/commit/0ae3385a67c7c3e1f3cabc5d940c2c9b568d074e). My hook plans are on hold, at least for now. I think [@onlyann](https://github.com/onlyann)...
> Yes. That would be similar to the hand rolled middleware from the docs. The main reason why I wrap `_process_job` instead of `ensure_async` is that an exception can be...
First, let us collect those relevant issues to provide an overview. I first created a label, but a milestone is more appropriate. I will call the milestone "Version 3.0".
> * I think it's about the first time where we have a few unrelated things to add to a single release. Do we want to create a milestone to...
Should we create a `next` or `v3` branch and add it to the CI action?
> Sure! Though I'm not sure we need to change things in the CI (we can add the fact that the CI runs on the branch after we merge), Hm....
It's more complicated than I thought. I also run some async stuff in my sync task, and this error doesn't seem to purely depend on Procrastinate. I will close this...
I investigated this a bit further. The above error happens as soon as I do a database access in the task, e.g.: ```python @app.task def example_task(): job = ProcrastinateJob.objects.first() assert...
Sure, I can add an integration test. It won't fail; pytest just provides it as a warning, but it will be visible on the console.
Just to keep you informed, it is not reproducible in Procrastinate itself, but we use a slightly different setup (Django 5, Psycopg 3). I will set up a minimal Django...