Regular Tasks

The Core uses tasks for recurring work such as updating credential states, deleting expired proof data, and retrying webhook notifications. Tasks do not run on their own: run each task you need on a schedule.

Tasks in your configuration

Tasks are configured in the task section of the Core configuration. Each key is a task name, and you run a task by its name:

task:
  LIFECYCLE_CHECK:            # Task name
    type: "LIFECYCLE_CHECK"   # Task type

• A name can differ from its type, and one type can have several instances under different names. Always run a task by its name.
• If you are using the base config, it already includes task instances you can run.
• An instance set to enabled: false cannot be run.

note

For what each task type does and which parameters it accepts, see Regular tasks in the Core configuration reference.

Running a task

Run a task from the command line or through the API.

Command line

Start core-server with --task and the task name. It runs the task, prints the result as JSON to stdout, and exits. On failure, it prints the error to stderr and exits with code 1.

core-server \
  --config <config-file> \
  --skip-migration \
  --task LIFECYCLE_CHECK

In the Docker image, the entrypoint is /app/core-server: pass the same flags as the container's arguments.

Flag	Description
--config	Configuration file. Pass the same configuration as the running Core.
--task	Name of the task to run.
--task-params	Optional. Task parameters as a JSON string, for example '{"forceRefresh": true}'.
--skip-migration	Skips database migrations. Without it, migrations run before the task.

API

Call the task endpoint with the task name and any task parameters:

POST /api/task/v1/run

{
  "name": "LIFECYCLE_CHECK",
  "params": {}
}

The response contains the task result. Calling the endpoint requires:

• Management endpoints enabled on the Core instance you call. See API Endpoint Zones.
• A caller with the TASK_CREATE permission.

Scheduling tasks

Run each task on its own schedule, using the scheduler of your deployment environment, such as a Kubernetes CronJob or cron. A separate schedule per task lets each one run at the interval it needs.

When run from the command line, a failed task exits with a non-zero code, so schedulers that track exit codes report failed runs.