Support Django 6's Django Tasks

[owais]

Django 6.0 introduces a background jobs API called Django Tasks. It does not ship with a worker implementation and expects users to bring their own. Right now there are zero prod ready backends (worker implementations). There is django-tasks module but it is far far from being prod ready.

Chancy looks great and it would be nice for Chancy to ship support for Django Tasks so Django projects could start Chancy workers and point their Django Tasks setting to use Chancy as the Tasks implementation.

[TkTech]

Work for this was in progress as part of the #58 release, not sure if it'll make it in for this release. There are a couple of pain points for behavior mapping:

• Chancy only supports keyword arguments, django tasks (lets call it DT) only supports positional arguments.
• Chancy supports retries as a job state, DT does not - do we retry anyways and just pretend it's still pending?
• Chancy does not capture job results by default, DT expects its - we can track when the task was enqueued by the DT framework and store the the result in the job's metadata, but we try to discourage this pattern by default.
• The supports async feature flag is either on or off, not per-Executor like it is in Chancy. All executors will currently accept async jobs, but that's not a guarantee. Might just leave this to the user to configure their queues properly.

Overall the implementation is tiny, and lives entirely within the existing django plugin.

[owais]

Looks like Django didn't really take many existing patterns into account when designing the APIs. That's a bit disappointing. Maybe this needs to exist as a best-effort implementation with hooks and config to let users customize behaviour like a settings map that maps each django task to chancy behaviour.

DJANGO_TASKS_CHANCY_MAP = {
   "myapp.tasks.task_one": {
       "retries": 4,
       "args_to_kwargs_mapper": mapper_func,
       ... # and so on
   }
}

This is ugly but I guess something like this would only be the last resort.

[TkTech]

Minimal support is now in #58

[jacobtylerwalls]

Hi, just doing some research on backend adoption for Django's tasks framework. Exciting to see this integration being added.

Chancy only supports keyword arguments, django tasks (lets call it DT) only supports positional arguments.

Tasks can be pushed/enqueued using keyword arguments, so I think I'm simply missing your meaning (since I'm not a Chancy user). Could you flesh this out a little? I'm curious if we need to land any tweaks in Django.

[TkTech]

Hi, just doing some research on backend adoption for Django's tasks framework. Exciting to see this integration being added.

Chancy only supports keyword arguments, django tasks (lets call it DT) only supports positional arguments.

Tasks can be pushed/enqueued using keyword arguments, so I think I'm simply missing your meaning (since I'm not a Chancy user). Could you flesh this out a little? I'm curious if we need to land any tweaks in Django.

This was really poorly worded on my part. Chancy only supports keyword arguments, to encourage good design when writing async tasks and to ensure we can later do structured validation. You don't want to rely on positional arguments when you may change the task signature while some old messages are still in flight. django-tasks allows both with no way to disable positional arguments. So in the implementation in #58 we wrap *args into a keyword argument, and a wrapper around your actual task takes care of unpacking it and calling your real task function. Not great but it's simple and works.