Moltaro 0.0.56-beta

Release date: 2026-09-10

Large imports and integrations no longer stop solely because a workspace has accumulated 100,000 retained mutation receipts. Seven-day replay protection is preserved, expired receipts are cleaned independently, and API and .NET callers receive accurate retry guidance when an individual operation reaches its limit.

Highlights

• Remove the workspace-wide mutation receipt limit that could block unrelated record and attachment operations during sustained imports.
• Preserve committed receipts for seven days while cleaning expired receipts in bounded background batches, independently of file and draft maintenance.
• Distinguish temporary operation capacity from conflicting key reuse and retain retry details in .NET command exceptions and failed import or bulk items.

Detailed changes

Sustained automation and replay protection

Mutation admission no longer counts or serializes the entire workspace receipt ledger. Independent actors and operation scopes can proceed without a shared workspace count limit. The separate guard of 1,000 live receipts for one actor and operation scope remains in place. Expired receipts do not consume it, and a matching retained replay is accepted even when that scope is full.

Existing receipts keep their original expiry. Reusing a retained key with a different request remains a conflict. After the seven-day replay window, integrations must reconcile the business outcome before retrying an old operation.

Expired receipts are removed by a dedicated Worker task, including when no new mutations arrive. It drains available batches without waiting for unrelated Markdown draft or file cleanup.

API and .NET failure handling

Capacity exhaustion retains the machine-readable code markdown.mutation.idempotencyCapacityExceeded; it is no longer reported as conflicting key reuse by the affected Entity adapters.

SecurityMutationError.Metadata preserves named decision details, including the server’s retry delay. ThrowIfFailed() carries those details into MoltaroSdkException, marks this capacity failure as retryable, and exposes a positive RetryAfterSeconds when supplied. Explicitly specified exception retry settings retain their existing meaning.

Failed import and bulk items expose SafeFailure.Metadata with capacity kind, current count, limit and retry delay. Resource identities and unrelated diagnostic metadata are excluded. Callers must inspect individual item outcomes as well as the outer command result.

Database and upgrade impact

No database schema or data migration is required. Existing receipt contents and their seven-day replay window are preserved; this release does not delete valid receipts to make room for new work.

Managed Apps receive a full runtime replacement with a brief interruption while their services restart. Standard pre-release database and runtime recovery points remain required. Returning to the previous runtime would restore its workspace limit and incorrect error classification. Restoring an older database would also discard subsequent writes and is not a routine way to undo this runtime change. Existing file-body backup dependencies are unchanged.

Deployment and operator actions

Deploy using ReplaceRuntime, including the matching Portal, public and agent documentation, Runtime VM agent 0.1.47 and all Managed App runtimes. The agent update delivers the matching backup-transfer tooling and its dependencies. Complete compatibility checks against every application before activation.

No server capacity override or manual receipt deletion is required. The dedicated maintenance defaults are a batch size of 1,000 and an interval of 60 seconds. Optional settings are Moltaro:MutationIdempotency:CleanupBatchSize (1–10,000) and Moltaro:MutationIdempotency:CleanupIntervalSeconds (1–3,600); changing them requires a host restart. The interval does not add a delay between available batches.

After runtime health is verified, resume any deliberately paused integration through its existing recovery procedure. Retry temporarily rejected operations with the same logical request and key after the advertised delay. Verify actual mutation progress with retained receipts above the former workspace limit.

Compatibility and breaking changes

Existing command method signatures and successful result shapes are unchanged. The failure DTOs add Metadata; clients with strict fixed-field deserialization must accept that field. Integrations must distinguish capacity exhaustion from changed-payload key reuse and honor its retry guidance instead of treating it as invalid source data. A retained replay still does not bypass authorization.