GitLab

We should not stop celery-monitor in case of temporary unavailability of redis
or cubicweb database.
Handle errors and automatically retry each 5 seconds.

This usecase (sending a serialized task signature as result of a task)  is
exceptional, so avoid flooding the logs with such messages.

Previously we handle monitoring celery task by listening to celery event bus
(celery.events.EventReceiver) that was not persistent. In this case we used a
dedicated routine (on_monitor_start) to synchronize non finished tasks, but
this wasn't working in case of an untracked task (eg. not started with
start_async_task). Also this was a single point of failure because it cannot
run in multiple instance without concurrency issues (events are sent to all
instances)

Now we use a redis queue where worker put task_id and task_name to be
synchronized and celery-monitor use brpop (https://redis.io/commands/brpop) to
process the queue.

We don't require CELERY_SEND_EVENTS to be enabled anymore (-E or --events in
worker options).
We require to add 'cw_celerytask_helpers.helpers' to CELERY_IMPORTS.

- strict policy on sql transaction (commit all or nothing for each task)
- make it work with on_monitor_start (used to synchronize task states when
  monitor starts in case of missing events)
- Use serializable() in "spawn" task so it force celery to use the json task
  serializer instead of pickle
- Don't always update task_name when creating subtasks outside of celerytask
  (eg. by using start_async_task), use a fixed identifier "<unknown>" as task
  name instead and only update these.

The view was called once and then being redirected to incontext view by
javascript code when task state changed.
Give the current vid to call on state change instead.

Add a method entity_content() to implement difference between incontext and outofcontext views.

Do not create a CeleryTask if no worker has aknowledge the said task.

celery.result.from_serializable is no more present in 4.x

it may occur that a transition cannot be fired due to a hook triggered by a
previous transition. Especially the on_monitor_start() was prone to this kind
of error since it was doing all the transitions in a single transaction.

[entities] improve workflow management of CeleryTasks (by celery-monitor) robustness (related to #16640842)

the transition may fail (if for some race-like reasons it has already been fired).

Also ensure some CeleryTask changes are commited (celery-monitor)
since the transaction may be rolled back during the WF management part of the
on_event() method.

including all the children subtasks' progress values

the celery configuration stuff for tests is not needed there

that returns an iterator on all parents recursively

when no task name has been set yet.

if a unknown log level is the first log statement, rows is empty.

so it is possible to write unit tests of cubicweb-celerytask related
stuff in other cubes.

This is done by listening at the celery event bus for 'task-xxx' events (which
is normally done by the celery-monitor cwctl command).

Needs to fix test_workflow_group since "Group task return the latest subtask"
is now wrong...

that yield the progress of the task and all the subtasks

almost the same as the incontext but uses the dc_long_title instead

the couple being (current_step, n_steps).
Also make the js code compatible with progress values given as a couple.

[entities] Determine task's state from db state if final, else on celery backend's if any (closes #16640866)

Relying on final db states avoids inconsistencies between the CW workflow
and celery-backend state, which should only be used to add real-time info.

When no reliable state can be found, return 'unknown state' explicitely.

Allowing to fire workflow transition in tests.

Some cubes use celerytask with CubicWeb 3.19