Eltheon Workload Runtime

Redeon.SuperSiteEngineCore.Web.Eltheon.Core.Features.Service is the canonical runtime for bounded jobs, supervised workers, and their triggers. The package name remains stable, but its former managed-service runtime is removed.

Runtime model

IEltheonJob performs bounded work and returns EltheonJobResult.
IEltheonWorker runs inside one supervised generation until cancellation.
EltheonJobDescriptor and EltheonWorkerDescriptor are immutable registrations.
IEltheonWorkloadCatalog validates unique keys, implementation contracts, ownership, policies, and default trigger bindings.
IEltheonJobDispatcher owns queueing, overlap policy, retries, timeout, cancellation, and attempt history.
IEltheonWorkerSupervisor owns start, stop, restart, availability, backoff, and generation identity.

services.AddEltheonServices();

The same registration contributes the scoped Adviser checks eltheon.service.worker-runtime and eltheon.service.trigger-runtime. They evaluate existing supervisor and trigger snapshots without serializing runtime options, exceptions, trigger configuration, or binding identifiers. Trigger subjects use the versioned full-SHA-256 format service-trigger:sha256-hex-v1:{digest}.

Feature packages register one descriptor and one matching keyed implementation:

services.AddSingleton(new EltheonJobDescriptor
{
    Key = "storage.cleanup",
    Owner = new EltheonWorkloadOwner(
        EltheonWorkloadOwnerKind.Feature,
        "storage"),
    DisplayName = "Storage cleanup",
    ImplementationType = typeof(StorageCleanupJob),
    DefaultEnabled = true,
    ExecutionPolicy = EltheonExecutionPolicy.Default
});
services.AddKeyedTransient<IEltheonJob, StorageCleanupJob>(
    "storage.cleanup");

Jobs and workers never derive from IHostedService. The central workload host owns scopes and cancellation.

Triggers

Startup, interval, cron, one-time, event, and file triggers dispatch jobs only. Trigger bindings are validated before activation and use stable schemas. Event contexts expose bounded allowlisted metadata; file contexts expose a configured root ID and relative path, never unrestricted filesystem access.

Trigger-specific policy overrides take precedence over persistent workload overrides, which take precedence over descriptor defaults. The runtime has no implicit cancel-previous behavior.

Persistence and upgrade behavior

The private eltheon.workloads Storage space contains:

configuration/workloads.json
configuration/triggers.json
bounded job and worker history

Descriptor defaults are materialized only when no trigger document exists. Package updates do not overwrite administrator configuration. Invalid or future-schema documents fail explicitly.

Old service configuration is detected read-only once per host generation, reported through WORKLOAD_LEGACY_CONFIG_IGNORED, and never imported or converted. New workload state always starts from descriptor defaults.

Admin, API, and Runtime Control

The feature-owned RCL contributes a single Services menu with five task-oriented Admin surfaces:

/Admin/Workloads provides an operational overview, explanations, KPIs, problem indicators, and recent activity.
/Admin/Services lists supervised workers and links to their lifecycle history.
/Admin/Workloads/Jobs explains registered jobs, their policies, trigger bindings, and direct execution.
/Admin/Workloads/Executions provides paged, filterable execution history and result details.
/Admin/Workloads/Triggers provides typed editors for startup, interval, cron, one-time, event, and safe-root file triggers.

Canonical API groups:

/api/v1/admin/workloads
/api/v1/admin/jobs
/api/v1/admin/executions
/api/v1/admin/workers
/api/v1/admin/triggers

GET /api/v1/admin/workloads/trigger-options supplies secret-safe editor options, including registered jobs, trigger types, browser-compatible time zones with platform aliases, registered events, misfire policies, event metadata, and configured file-root identifiers. The paged GET /api/v1/admin/executions query accepts job, status, source, time-range, page, and page-size filters with a maximum page size of 100. GET /api/v1/admin/workers/{key}/history exposes the already persisted, bounded worker lifecycle history.

Trigger configuration JSON remains the internal provider transport and storage format. It is deliberately absent from the Admin UI. Creating a trigger uses POST; editing a selected trigger reconstructs its typed fields and uses PUT /api/v1/admin/triggers/{id}. Enable, disable, and delete stay separate, confirmation-aware operations.

Runtime Control keys:

queries: workloads.list, jobs.status, jobs.history, workers.status, triggers.list
commands: jobs.execute, jobs.cancel, workers.start, workers.stop, workers.restart

Mutating API and Runtime Control operations require the workload execute/configure permissions and preserve the existing confirmation and ProblemDetails conventions. Read operations require System.Workloads.View. Navigation filtering is not authorization.

The interactive Admin UI uses the centrally provided EltheonJS Full modules (api, templatingExt, bind, optional realtime.admin, Lifecycle, and pageManager) inside the existing Assan Admin theme. The feature script is loaded through the page Scripts section from /_content/Redeon.SuperSiteEngineCore.Web.Eltheon.Core.Features.Service/eltheon/features/service/workloads-admin.js after the Admin theme bundle. It adds neither a second client framework nor a separate CSS pipeline. Realtime refreshes do not replace a trigger form while it contains unsaved changes.

Execution results may carry up to 16 secret-safe scalar ResultFacts. The coordinator copies them into terminal execution snapshots, and the Admin details render their localized display names and values. Persisted snapshots from versions without result facts remain readable as an empty fact list.

Events and metrics

Canonical events are declared by WorkloadEventNames under Eltheon.Workloads.*. Metrics are declared by WorkloadMetricDefinitions:

eltheon_workload_job_executions_total
eltheon_workload_job_duration_seconds
eltheon_workload_job_queue_depth
eltheon_workload_job_active_executions
eltheon_workload_worker_state
eltheon_workload_worker_restarts_total
eltheon_workload_trigger_fires_total
eltheon_workload_trigger_failures_total

Metric labels are bounded to workload key, kind, result/state, and trigger type. Payloads, paths, users, exceptions, and execution IDs are not metric labels.

Plugin workloads

Manifest-v3 plugins declare workloads and register implementations with AddEltheonPluginJob<TJob> or AddEltheonPluginWorker<TWorker>. In-process and isolated-worker contributions enter the same catalog and runtime policies. Deactivated plugin owners become unavailable; their worker generations stop, while already admitted jobs may complete.

Breaking change

The former service contracts, manager, adapter, trigger registry, configuration models, legacy Admin implementation, API routes, Runtime Control aliases, plugin service helpers, and protocol messages were removed. The current /Admin/Services page is a worker-focused projection of the Workload runtime; it is not a compatibility adapter and does not restore the old Services API. There is no automatic configuration migration. Follow docs/Eltheon_Phase_4_16_Service_v3_Upgrade_Guide.md.

Redeon.SuperSiteEngineCore.Web.Eltheon.Core.Features.Service

Install-Kommandos

Vorschau