Skip to content

Run a task manually

The diracx-tasks call command executes a single task interactively, bypassing the broker. This is useful for debugging, manual recovery, and verifying task behaviour.

Basic usage

diracx-tasks call <entry_point> --args '<JSON list>'

The entry point name is <category>:<ClassName> as registered in pyproject.toml. For example:

diracx-tasks call lollygag:SyncOwnersTask --args '["alice"]'

Passing arguments

  • --args: JSON list of positional arguments passed to the task constructor (default: [])
  • --kwargs: JSON dict of keyword arguments (default: {})
diracx-tasks call lollygag:SyncOwnersTask --args '["alice"]' --kwargs '{}'

Run the dummy compute backend

The dummy compute backend pretends to run the parcels of the Transformation System, which are kept in the TransformationDB. The periodic transformations:DummyComputeBackendMonitorTask claims Unassigned compute parcels, moves them through Reserved to Assigned on the dummy backend, and schedules a one-shot transformations:DummyComputeBackendTask for each, which walks the parcel through Completing to Done and moves its inputs to Processed. See Dummy compute backend for how it works.

Automatic monitoring is disabled by default. run_local.sh enables it every 10 seconds with DIRACX_TASKS_DUMMY_COMPUTE_BACKEND_ENABLED=true and DIRACX_TASKS_DUMMY_COMPUTE_BACKEND_INTERVAL_SECONDS=10. Both tasks need DIRACX_DB_URL_TRANSFORMATIONDB.

Run the monitor once to submit the waiting parcels:

diracx-tasks call transformations:DummyComputeBackendMonitorTask

Or complete a single Assigned parcel by passing its identifier:

diracx-tasks call transformations:DummyComputeBackendTask --args '["0199c5a4-7c1e-7d3f-8a2b-3c4d5e6f7a8b"]'

Debugging

The --debugger flag drops into Python's debugger:

  • --debugger before: break before task execution
  • --debugger exception: break on unhandled exception (post-mortem)
diracx-tasks call lollygag:SyncOwnersTask --args '["alice"]' --debugger exception

Lock behaviour in interactive mode

When DIRACX_TASKS_REDIS_URL is set, structural locks (MutexLock, ExclusiveRWLock, SharedRWLock) are still acquired — this prevents accidentally corrupting shared state. Limiters (RateLimiter, ConcurrencyLimiter) are skipped, so the task runs without being throttled.

If DIRACX_TASKS_REDIS_URL is not set, no locks are acquired at all.

Listing available tasks

To see which tasks are registered, run the command with an invalid entry point name:

diracx-tasks call nonexistent
# Task 'nonexistent' not found. Available: ['lollygag:OwnerCleanupTask', 'lollygag:OwnerReportTask', 'lollygag:SyncOwnersTask']