App Execution Lifecycle

One of the most important things to understand about Lombok is how an app moves from manifest definition to actual execution.

This page explains that lifecycle at a high level.

1. App declares its capabilities

A Lombok app starts with a config.json manifest.

That manifest declares things such as:

subscribed core events
triggers
tasks
runtime workers
UI support
settings
contributions

At this stage, the app is describing what it can do.

A trimmed source-aligned example looks like this:

{
  "subscribedCoreEvents": [
    "core:object_added",
    "core:object_removed",
    "core:object_updated"
  ],
  "triggers": [
    {
      "kind": "event",
      "eventIdentifier": "core:object_added",
      "taskIdentifier": "demo_object_added_worker_task",
      "onComplete": [
        {
          "taskIdentifier": "demo_worker_task_on_complete"
        }
      ]
    },
    {
      "kind": "schedule",
      "triggerKey": "hourly_job",
      "config": {
        "kind": "interval",
        "interval": 1,
        "unit": "hours"
      },
      "taskIdentifier": "demo_scheduled_worker_task"
    },
    {
      "kind": "schedule",
      "triggerKey": "weekday_morning_job",
      "config": {
        "kind": "cron",
        "expression": "0 9 * * 1-5",
        "timezone": "UTC"
      },
      "taskIdentifier": "demo_scheduled_worker_task"
    }
  ],
  "tasks": [
    {
      "identifier": "demo_object_added_worker_task",
      "handler": {
        "type": "runtime",
        "identifier": "demo_object_added_worker"
      }
    }
  ]
}

2. Lombok registers the app model

When Lombok loads or installs an app, it interprets the manifest and records the app’s available capabilities.

That includes understanding:

which events the app wants
which triggers exist
which tasks exist
which workers are available
which parts of the UI the app contributes

3. An event or schedule activates the app

Execution usually starts with one of two things:

a core event
a schedule trigger

Examples visible in the codebase and demo app include:

core:object_added
core:object_removed
core:object_updated
interval schedules
cron schedules

The broader source also includes other events such as folder_scanned, new_user_registered, and internal task-enqueueing events.

4. A trigger selects a task

The app’s triggers map those events or schedules to task identifiers.

This is where Lombok moves from:

“something happened”

into:

“run this specific task for this app”

5. The task resolves to a handler

A task definition points to a handler.

In the current model, this commonly means:

a runtime handler

The broader type system also supports:

a docker handler type

6. The worker runtime executes the work

Once the task has been resolved, Lombok executes the underlying worker through the worker runtime.

The primary execution model should be understood as runtime-worker execution through Lombok’s worker system rather than Docker-first execution.

7. Results flow back into the platform

During and after execution, Lombok can surface:

progress
logs
completion status
follow-up actions

The app model also supports completion chains through onComplete behavior in triggers.

8. The UI can reflect execution results

Depending on the app and feature area, results may be reflected through:

main platform UI
embedded app UI
task state
follow-up events

Why this lifecycle matters

The app lifecycle explains why Lombok’s app platform is more than just:

a plugin system
a UI extension mechanism
a simple event handler registry

It is a structured pipeline that connects:

declaration
orchestration
execution
user-facing results

Next steps

Continue with: