Manage Taskstream job capabilities safely

Use this page when you inspect or convert Taskstream jobs in Automation > Taskstream > Jobs. It explains why some scheduler or runnable types do not appear, why a historical value can be visible but locked, and how to verify that the job editor has failed safely.

Taskstream currently operates under a restricted security contract. Treat the types offered by Workspace as the current editing contract, not as a promise that every job will execute successfully. The server validates permissions, tenant ownership, authority, policy freshness, containment, and runtime availability again when you save or run a job.

Check the offered types

  1. Open Automation > Taskstream > Jobs.
  2. Open the create dialog or an existing job.
  3. Review both the scheduler and runnable type lists.
  4. Use only types offered for the current tenant.

Workspace loads these lists and their defaults from the server. If the capability response is empty, invalid, or unavailable, the editor uses a safe fallback. That fallback does not enable event, inotify, http, shell, or lua.

The current restricted contract offers cron, interval, delay, instant, and time for new or changed jobs. event can also appear when the server confirms the exact tenant feature taskstream.scheduler.event, its current policy revision, and the persistent watch contract of the runtime. The feature remains disabled by default. The inotify scheduler and the runnable types http, shell, and lua remain contained. The event runnable can appear only when the server confirms its separate tenant feature taskstream.runnable.event, its current policy revision, and the registered executor. One feature never enables another capability.

Configure an event runnable

Enter a lowercase logical topic of no more than 128 characters. It must start with a letter from a to z or a digit; the remaining characters may also include a dot, underscore, or hyphen. The optional payload must contain only JSON data and must not exceed 64 KiB after serialization.

Workspace binds the event to the current tenant and creates the private topic namespace and envelope identity itself. Job data cannot select a general domain topic or provide metadata, credentials, authority, or another tenant. The publish is process-local; it is not a persistent or cluster-wide delivery promise.

Select the event scheduler only when the current capability response offers it. Enter a logical topic that follows the same limited format. The scheduler binds its subscription to the current tenant and job. Exactly one cluster owner holds a time-limited watch lease for a job, and a monotonic fence rejects stale owners. Repeated delivery of the same non-empty envelope ID does not create a second occurrence for the same job generation and topic.

The server permits at most 32 reactive watches per tenant and 256 per node. It removes the subscription within two seconds after feature or revision revocation, lease loss, pause, archive, stop, or shutdown. The bus is still process-local: publisher and scheduler must reach the same engine process. The watch lease prevents duplicate cluster owners; it does not provide a cluster-wide event transport.

If a runnable or scheduler feature revision changes, the saved job requires another review. Execute and Unarchive validate the existing binding and do not renew it. Review the complete job, then use a full PUT replacement or Resume to create a new authorized generation. Never repair the binding directly in the database.

Deploying the separate rootless OCI runner does not change these lists. It is only the isolated technical prerequisite for future shell and Lua contracts. Positive runner readiness enables no feature and unlocks no historical job. Operators can continue with Prepare the Taskstream runner safely.

Review a historical locked job

A historical job can contain a scheduler or runnable that the server no longer offers. Workspace keeps the stored value visible so that you can review the record, but disables its configuration controls and the Resume and Execute actions. Merely opening the job does not replace or write back the value.

If the job is still required, review its purpose and convert the complete job to both a currently offered scheduler and a currently offered runnable. Save the full replacement only after that review. Do not treat a similar-looking type as an automatic equivalent.

Check safe fallback behavior

The editor has failed safely when all of these conditions hold:

  • risky scheduler and runnable types are absent after a capability error;
  • historical unavailable values remain visible but locked;
  • Resume and Execute stay disabled unless both current types are offered;
  • selecting an offered type preserves the server-provided defaults; and
  • Inotify never receives a client-side path default, especially not an absolute /tmp path.

If the lists differ from the server contract, reload the page once. If the problem remains, stop editing the job and ask an operator to inspect the Taskstream capability endpoint and policy state. Do not repair the record with direct database changes.

For retention periods, sanitized history, and legal holds, continue with Taskstream history and retention.