Events & Tasks

In Lombok, events, triggers, tasks, and workers are distinct, source-defined concepts. This page enumerates the concrete event names, task names, trigger kinds, and the mappings the platform source actually defines.

The execution model is:

Something happens in Lombok (or an app emits its own event).
An event record is created.
A matching trigger (event-, schedule-, or user-action-based) resolves to a task.
The task is dispatched to a worker (runtime or docker).
The worker reports progress, logs, and a final completion (success or error) back to the platform.

Source of truth

The authoritative definitions live in the app repo:

Concept	File
Event names & identifier rules	`packages/types/src/events.types.ts`
Trigger, task, progress & invocation schemas	`packages/types/src/task.types.ts`
Core task names & data shapes	`packages/api/src/task/task.constants.ts`
Built-in event→task mapping	`packages/api/src/task/constants/core-tasks.constants.ts`
Manifest schema & validation	`packages/types/src/apps.types.ts`

Events

Core events

CoreEvent (events.types.ts) enumerates the events the platform itself emits:

`CoreEvent` value	Emitted identifier
`object_added`	`core:object_added`
`object_removed`	`core:object_removed`
`object_updated`	`core:object_updated`
`folder_scanned`	`core:folder_scanned`
`serverless_task_enqueued`	`core:serverless_task_enqueued`
`docker_task_enqueued`	`core:docker_task_enqueued`
`new_user_registered`	`core:new_user_registered`

Identifier rules

Two schemas constrain event identifiers:

Bare identifier — eventIdentifierSchema: non-empty, matches ^[a-z_]+$. Used for app-emitted events.
Core-prefixed identifier — corePrefixedEventIdentifierSchema: matches ^core:[a-z_]+$. Used wherever a platform event is referenced.

The core namespace comes from CORE_IDENTIFIER = 'core'.

Emission & matching

From the event service behavior:

When the core platform emits an event, it is stored and matched as core:<event>, and enabled apps whose subscribedCoreEvents include that identifier are candidates to receive it.
When an app emits an event, the emitter is the app’s identifier and the event uses the bare identifier. That event is delivered to the emitting app’s own triggers.

Built-in event → core-task mapping

CORE_EVENT_TRIGGERS_TO_TASKS_MAP defines the platform’s own reactions to core events. It is a partial map:

Core event	Core task	Condition
`object_added`	`analyze_object`	always
`new_user_registered`	`send_email_verification_link`	`userEmail` present and `userEmailVerified === false`
`docker_task_enqueued`	`run_docker_worker`	always
`serverless_task_enqueued`	`run_serverless_worker`	always

object_removed, object_updated, and folder_scanned are valid events but have no built-in core-task mapping here.

Triggers

A trigger binds an event, schedule, or user action to a task. taskTriggerConfigSchema is a discriminated union on kind. All trigger kinds share a base: taskIdentifier, optional condition, optional onComplete[], optional onProgress[].

`kind`	Adds	Runtime-registerable?
`event`	`eventIdentifier`, optional `dataTemplate`, optional `triggerKey`	Yes
`schedule`	`config`, required `triggerKey`	Yes
`user_action`	optional `scope`	No

Event triggers

{
  "kind": "event",
  "eventIdentifier": "core:object_added",
  "taskIdentifier": "demo_object_added_worker_task"
}

eventIdentifier accepts a bare identifier or a core:-prefixed one.
triggerKey is optional.
dataTemplate lets the trigger shape the task’s data from the event.

Schedule triggers

scheduleConfigSchema has two variants:

Interval

{
  "kind": "schedule",
  "triggerKey": "hourly_job",
  "config": { "kind": "interval", "interval": 1, "unit": "hours" },
  "taskIdentifier": "demo_scheduled_worker_task"
}

Cron

{
  "kind": "schedule",
  "triggerKey": "weekday_morning_job",
  "config": { "kind": "cron", "expression": "0 9 * * 1-5", "timezone": "UTC" },
  "taskIdentifier": "demo_scheduled_worker_task"
}

Source constraints:

triggerKey is required on schedules.
Cron is 5-field only.
Sub-minute granularity is rejected.
timezone defaults to UTC when omitted.

User-action triggers

Declared only in the manifest. Optional scope may narrow by user permissions and/or a specific folder.

Conditions

Any trigger (and onComplete/onProgress handler) may carry a condition string. In source it is validated only for safety, not against a field whitelist.

Tasks

A task is a named unit of work declared in the manifest:

{
  "identifier": "demo_object_added_worker_task",
  "label": "Demo Object Added Worker",
  "description": "A task that runs for every newly added object.",
  "handler": { "type": "runtime", "identifier": "demo_object_added_worker" }
}

Key rules:

identifier matches ^[a-z_]+$
handler.type is runtime or docker
runtime handlers must point at a declared runtime worker
docker handlers must point at a declared container-profile job

Core tasks

CoreTaskName enumerates the platform’s own task identifiers, described in CORE_TASKS:

`CoreTaskName`	Identifier	Description
`AnalyzeObject`	`analyze_object`	Generate metadata and previews for an object
`ReindexFolder`	`reindex_folder`	Reindex a folder and its contents
`RunDockerWorker`	`run_docker_worker`	Run a docker worker to execute a task
`RunServerlessWorker`	`run_serverless_worker`	Run a serverless worker to execute a task
`SendEmailVerificationLink`	`send_email_verification_link`	Send email verification link to a newly signed-up user
`CreateEventNotifications`	`create_event_notifications`	Create notification records for an event or group of events
`BuildNotificationDeliveries`	`build_notification_deliveries`	Create notification delivery records for a unique notification
`SendNotificationEmails`	`send_notification_emails`	Send batched notification emails to users

Only a subset of these are wired directly from core events via CORE_EVENT_TRIGGERS_TO_TASKS_MAP.

Completion chains (`onComplete`)

onComplete lets a task enqueue follow-up tasks when it finishes. It is recursive.

Progress chains (`onProgress`)

onProgress reacts to a parent task’s progress reports rather than completion.

Invocation context

When a task runs, its invocation carries a kind describing why it ran:

`kind`	Key context fields
`system_action`	optional `idempotencyData`
`event`	`eventId`, `emitterId`, `eventIdentifier`, `eventData`, optional `triggerKey`, `targetUserId`, `targetLocation`
`schedule`	`timestampBucket`, `triggerKey`, `config`
`user_action`	`userId`, `requestId`
`app_action`	`requestId`
`task_complete_child`	parent task context
`task_progress_child`	parent task context

Workers & execution

handler.identifier resolves to a worker. Runtime workers are declared in runtimeWorkers.

The executor that runs a task reports executorMetadata, a discriminated union on type:

system
docker
runtime

Progress reporting

While running, a worker may emit TaskProgressReports with:

code
details
message
timestamp
executorMetadata

Separately, the platform broadcasts lifecycle updates via TaskUpdateType:

task_started
task_progress
task_completed
task_requeued
task_failed

Logs

A TaskDTO carries two log streams:

system log
task log

Completion & retries

A task ends with a TaskCompletion on either the success or error path. On the error path the executor may set requeueDelayMs to retry later. The platform caps attempts at MAX_TASK_ATTEMPTS = 5.

Event notifications

events.types.ts also defines notification aggregation used by notification-related core tasks. EventNotificationAggregationScope is one of:

SERVER
FOLDER
FOLDER_OBJECT

Manifest validation relationships

The manifest schema enforces these cross-references:

core: event triggers must appear in subscribedCoreEvents
trigger task identifiers must point at declared tasks
runtime handlers must point at declared runtime workers
docker handlers must point at declared container-profile jobs
runtime worker entrypoints must exist in the uploaded bundle manifest

Worked example: the demo app

The simple demo app wires:

core event subscriptions
an event trigger on core:object_added
two schedule triggers
runtime-worker-backed tasks