Moltaro 0.0.17-beta

Release date: 2026-08-11

This release restores scheduled business-function execution after a Managed App container replacement leaves stale run history linked to an already terminal queue job. It lets blocked schedules retry safely without bypassing the active job guard or duplicating work on another live worker.

Highlights

• A function run that remains Running after its linked job reaches Completed, Failed, or Cancelled is reconciled automatically even when the replacement Worker has a different container hostname.
• Queued and Leased jobs owned by another worker remain protected, so the recovery path cannot start a duplicate attempt while active work may still be executing.
• The operations documentation now states the terminal-job reconciliation and cross-worker safety contract explicitly.

Detailed changes

Business-function recovery

• Orphaned-run discovery now includes active run rows whose linked BusinessFunctionJob is terminal. Terminal queue state is a stronger recovery fact than recorded machine identity because the supported queue lifecycle reaches a terminal job state only after execution has stopped.
• The recovery service closes the inconsistent run as StoppedByWorkerRestart, records a terminal-job-specific diagnostic, and preserves the linked terminal job rather than rewriting its historical outcome.
• Existing same-host dead-process and stale ownerless-run recovery remains unchanged.
• Foreign-host runs linked to Queued or Leased jobs are intentionally excluded, preserving the active-run and unique-index guards against duplicate side effects.
• Regression coverage includes Completed, Failed, and Cancelled jobs, the active foreign-host negative case, job-processor startup recovery, and schedule active-run uniqueness.

Database and upgrade impact

There is no Workspace/Portal schema change, migration, backfill, or bulk rewrite. Existing inconsistent function-run rows are reconciled by the normal Worker recovery service after startup; operators must not edit run or job tables. Each Managed App has only ordinary full-replacement downtime. Keep the Deployctl recovery points and use coordinated recovery rather than manual data edits.

Deployment and operator actions

• Publish 0.0.17-beta as a full Managed App runtime replacement for every production Managed App. Do not prepare or apply a delta update package.
• Use the interactive production Deployctl workflow to publish Portal, StorageSigner, regenerated public documentation, the base runtime package, and the mandatory Runtime VM agent artifact before replacing the three Managed Apps.
• Preserve every Workspace database, managed file-body binding, object-storage bucket, and available backup. No configuration, credential, capability, object-storage policy, or client package change is required.
• After deployment, verify Portal, both signer replicas, Runtime VM agent, public and API routes, and all API, WebApp, Worker, and RabbitMQ containers for every Managed App. Confirm exact runtime version, zero unexpected restarts, healthy queues, and no recent Worker/API failures.
• For OMS acceptance, use the existing hourly ventcontrol.syncLegacyCatalogs schedule. Confirm the stale run is recovered, the retry-eligible LFI3638 issue is processed, the Order receives one Available attachment with matching source bytes, the issue resolves, and a later occurrence is idempotent. Do not create a duplicate schedule, invoke a test-only path, upload the file manually, or modify production tables.

Compatibility and breaking changes

No known compatibility or breaking changes. No supported Runtime API, Portal API, Package SDK contract, persisted business-data schema, job status, run status, agent protocol, or client configuration changes.

The only behavioral change is recovery of an internally inconsistent Running run when its linked queue job is already terminal. Active Queued and Leased cross-worker behavior is unchanged.