FAQ === **Q.** Why? **A.** For the most part, due to the issues laid out in the :doc:`Compare with Celery `, which is the current uncontested incumbent in the Python task queue space. While there are many alternatives, none of them checked off all of the boxes needed for my existing projects to migrate off of Celery. ----- **Q.** Why not sell 'pro' features like Oban Pro and Sidekiq Pro? **A.** Chancy is not the product - it's a tool used in my *actual* products. Having a fully open and community-driven project benefits all of the projects using it. The more users using workflows, dashboards, etc the more reliable and robust the project becomes for the revenue-generating products built on it. ----- **Q.** Why ``Job`` instead of ``Task``? **A.** To simplify developer QoL when merging with existing codebases that already use Celery, Chancy uses the term "job" instead of "task". That way you can import: .. code-block:: python from chancy import Job from celery import Task ... and progressively migrate your codebase to Chancy without having to rewrite all of your tasks or alias the imports. ----- **Q.** Why can't I just do ``job.delay()``? **A.** Supporting ``job.delay()`` like Celery does would require global state to keep track of the currently active Chancy application. Chancy has **absolutely no global state** as a hard rule, which helps minimize the risk of bugs when dealing with many different types of concurrency models in a single application. ----- **Q.** Why not use advisory locks to make implementation of some features easier? **A.** Advisory locks don't support any form of namespacing - they're just a numeric ID. This makes them unsuitable for use in a multi-tenant system where you might have multiple different applications using the same database. Advisory locks also have several issues when used with pgbouncer that might stop us from officially supporting pgbouncer in the future.