Moltaro 0.0.31-beta

Release date: 2026-08-28

This release makes function failures consistently diagnosable, prevents interrupted managed-file uploads from becoming stuck or ambiguously reusable, and gives Work Schedule administrators a complete actionable readiness list.

Highlights

• Every failed terminal business-function run now has a stable, non-empty reason code. Queued retries and exhausted jobs preserve the exact current-run code instead of falling back to exception text or losing the cause.
• Managed multipart uploads distinguish explicit user aborts from safe runtime recovery. Interrupted attempts retain bounded recovery codes, clean up their provider state, and permit exactly one logical successor only after cleanup has completed.
• Work Schedule administration shows every catalog, field, surface, and published-calendar blocker as its own actionable item, with direct Create, Repair, Open, or Fill data actions.

Detailed changes

Function runtime diagnostics

• Terminal ValidationFailure, PermissionFailure, Timeout, RuntimeException, and StoppedByWorkerRestart runs receive stable fallback codes when a typed SDK or platform exception did not already provide a more specific code. Successful, skipped, and explicitly cancelled runs remain code-free.
• Queue retry and exhaustion transitions resolve the exact persisted run for the current attempt and correlation id. Protected run-consistency failures take precedence and stay terminal; isolated-runner timeouts, unexpected child exits, and parent-side failures follow the same contract.
• Run and job APIs expose the machine-readable code without deriving it from localized messages. Entity-context projections retain their existing redaction boundary and do not expose arguments, results, exception text, stack traces, payloads, or secrets.

Managed file upload recovery

• Runtime-owned cancellation, missing or terminal source runs, terminal source jobs, and expired source leases use distinct filesystem.upload.recovery.* codes. Explicit user aborts remain final and do not receive a recovery code.
• Upload begin, abort, cleanup, garbage collection, and successor creation now serialize on the logical operation and generation lifecycle. Late completion or abort work cannot relabel an already terminal explicit abort or leave a stale provider upload identifier behind.
• A recovery-aborted physical attempt can create a successor with the same logical idempotency key only after the predecessor generation is confirmed deleted. While cleanup is pending, callers receive a retryable structured conflict instead of overlapping provider generations.
• Package SDK attachment results expose the safe recovery code for an Aborted attempt. A published result still wins idempotently and an explicit discard never becomes restartable.

Work Schedule readiness

• The settings page no longer collapses additional diagnostics behind a count. Every missing definition, protected field/value, required working surface, default, selector, action, and calendar prerequisite is visible separately.
• Each item names the affected catalog and field or surface and links to the supported remediation path. Responsive icon actions retain accessible labels on narrow screens, and the complete wording is available in English, Ukrainian, German, Polish, and Spanish.

Database and upgrade impact

No Workspace or Portal schema migration and no customer-data migration are introduced by this release. Each Managed App still has ordinary full-runtime replacement downtime while its recovery point is captured and API, WebApp, Worker, package runtime, and broker health are replaced and verified.

Rollback uses the verified pre-release recovery point together with the previous runtime image. The release does not require an administrator to transform data or reconfigure existing applications.

Deployment and operator actions

• Publish 0.0.31-beta with full ReplaceRuntime for all three production Managed Apps. Do not prepare or apply an update package.
• Preserve the attached Runtime VM staging volume, automatic Managed App backups, Object Storage bindings, application secrets, and Workspace databases. The latest automatic attempt for every application must be Available before production mutation.
• After replacement, verify exact target images, API/WebApp/Worker/RabbitMQ readiness, empty active operation queues, current Runtime VM agent health, and the OMS function-run, file-upload, and Work Schedule administration canaries.
• No new infrastructure setting, credential, or customer configuration is required.

Compatibility and breaking changes

There are no known breaking API or schema changes. Clients that inspect failed function runs or queued jobs can now rely on a non-empty reason code for every failed terminal outcome. Package SDK consumers may now observe a safe filesystem.upload.recovery.* FailureCode on runtime-recovered Aborted transfers; an explicit caller abort continues to return no failure code. Code that treated every Aborted result as an explicit user discard should use the failure code to distinguish the two outcomes.