## Why is it needed

Odoo historically only supports two ways of processing tasks. Sporadic HTTP request and periodic CRON tasks. The former is the preferred way to exchange information with the web application while the later is used to perform some regular background batch operations.

Several models need to create sporadic background tasks assured to be processed as soon as possible. The current strategy of doing so is to save the task in some kind of queue later processed by a CRON. This strategy lacks reactivity due to low frequency of CRON calls. e.g. (e)mail or marketing "send/start now" button, payment transactions. Another strategy used by the stock app to compute the procurement is to start the processing in a new thread.

Another problem comes when the user call and very resource-demanding endpoint via a HTTP request. HTTP requests are limited in time to prevent worker starvation (i.e. when no worker is available to process new requests), in some extreme circumstances legitimate requests are discarded because they timeout. In order to prevent starvation, it is necessary to process those very resource-demanding requests independently from the HTTP request. Extreme circumstances include among others huge import/export (several billion records).

## Asynchronous server tasks

We introduce a new API to schedule and process asynchronous tasks with optional web notification.

Tasks are classic model method call on record sets, the difference is that the call is not performed by the current worker but rather enqueued to be processes asap by a brand new "async" worker.

Tasks are securely process in their own transaction meaning they are either completely executed or not executed at all. Tasks that are cancelled due to a server crash or a forced shutdown are left enqueued for the next run.

Scheduling a task is done via the `env['ir.async'].call` method. The first argument is a Odoo model method bound to a record set, the later are positional and keyword arguments to perform the call with. People use to the python standard libraries `functools.partial`, `threading.Thread` and `multiprocessing.Process` functions will acknowledge a similar signature.

## User notification

Using `call_notify` instead of `call` triggers web notifications. Notifications are send to the current user on task creation, processing and termination. A new systray menu has been added so the user can keep track of all those background tasks.

Upon termination, the user is notified with the result (or an error if the task failed). The result is by example an `ir.actions` the user can execute by clicking the item in the systray.

The result is kept up to three days server side. One can start an heavy export the Friday evening and gather the result the next Monday morning.