Celery Tasks

Every command, eval, or method-style verb call runs as a Celery task. This page is the reference for the three task functions defined in moo.core.tasks. For the verb-author entry points (:func:moo.sdk.invoke, :func:moo.sdk.set_task_perms, :func:moo.sdk.task_time_low, :func:moo.sdk.schedule_continuation), see SDK Functions and Advanced Verb Patterns.

Available tasks

moo.core.tasks.parse_command(caller_id, line)

Parse a command-line and invoke the requested verb.

Parameters:

  • caller_id (int) – the PK of the caller of this command

  • line (str) – the natural-language command to parse and execute

Return type:

tuple[list[Any], int]

Returns:

(output, exit_status) — list of output lines and 0 on success, 1 if any caught exception fired.

Raises:

UserError – if a verb failure happens

moo.core.tasks.parse_code(caller_id, source, runtype='exec')

Execute code in a task.

Parameters:

  • caller_id (int) – the PK of the caller of this command

  • source (str) – the Python code to execute

Return type:

tuple[list[Any], Any]

Returns:

a list of output lines and the result value, if any

moo.core.tasks.invoke_verb(*args, caller_id=None, player_id=None, this_id=None, verb_name=None, callback_this_id=None, callback_verb_name=None, **kwargs)

Asynchronously execute a Verb, optionally returning the result to another Verb. The print() method routes output to the triggering player’s message queue when player_id is provided, otherwise falls back to the background log.

Parameters:

  • caller_id (Optional[int]) – the PK of the context caller (for permission checks)

  • player_id (Optional[int]) – the PK of the triggering player; print() output routes to this player

  • verb_id – the PK of the Verb to execute

  • callback_verb_id – the PK of the verb to send the result to

Return type:

None

invoke_verb is the only task verb authors interact with — and they do that via the :func:moo.sdk.invoke helper rather than calling the task directly. invoke() enforces wizard checks for periodic=True and cron=... schedules and verifies that the caller has execute on the target verb.

Task isolation and limits

Each task runs as a separate Celery process. The isolation guarantees are:

  • Process isolation. A memory race or runaway loop in one verb cannot affect other concurrent tasks. Worker memory and CPU can be bounded by the OS.

  • Atomic database transaction. Every verb invocation runs inside a Django transaction.atomic() block. An uncaught exception rolls back every database change made during the task.

  • Hard time limit. The time budget is read from the CELERY_TASK_TIME_LIMIT environment variable in moo/celeryconfig.py (default 3 seconds). When the limit elapses, Celery terminates the worker process. Synchronous calls to other verbs share that budget — see Advanced Verb Patterns for the time-aware continuation pattern that hands off remaining work to a fresh task.

  • RestrictedPython sandbox. Verb source is compiled and executed inside Zope’s RestrictedPython. Imports, builtins, and dunder attribute access are restricted; see Verb Sandbox Security Reference for the full guard model.

Inspecting the current task from verb code

context.task_id returns the Celery task ID for the running invocation. context.task_time returns a TaskTime(elapsed, time_limit, remaining) namedtuple — useful when you need to bail out early before the worker kills the task. See The DjangoMOO Runtime for the full context reference.