Release v2.1.0

Choreography can now apply one-time data changes when a release starts, and it does so without taking the old release down. A rolling upgrade no longer needs the replica set scaled to zero and back up: new pods start while old pods keep serving.

Added

• Startup patching: implement ICanApplyPatch and the patch is discovered, ordered by version and applied once per store before the silo takes work.
• A cluster-wide patch manager grain that is safe in mixed-release clusters. When a newer host asks an older manager, the manager moves to the newer host before patching, and an older host never patches a store a newer host already patched.
• Resilient startup during rollouts: a lost silo, a rejected message or a patch that outlasts the grain response timeout is retried with back-off instead of failing the start, bounded by PatchingOptions.MaxWait (15 minutes by default) and reported as PatchingDidNotComplete.
• Patch storage for in-memory, MongoDB and SQL (SQL Server and PostgreSQL) stores, with the SQL tables created by Choreography's own migrations.
• AddCratisChoreographyPatching and CratisChoreographyOptions.ConfigurePatching to turn patching on and tune it.
• Complete documentation, reorganized by feature area, with a patching section and troubleshooting entries.

Release v2.0.0

Cratis.Orleans is now Cratis Choreography: the runtime for durable business processes on Orleans — workflows, state machines, jobs, storage and silo hosting. This is a breaking release.

Changed

• Packages are renamed: Cratis.Orleans is now Cratis.Choreography, and Cratis.Orleans.Storage, Cratis.Orleans.Storage.MongoDB, Cratis.Orleans.Storage.Sql and Cratis.Orleans.Chronicle follow as Cratis.Choreography.Storage, .Storage.MongoDB, .Storage.Sql and .Chronicle. Replace the package references and change Cratis.Orleans to Cratis.Choreography in your namespaces and using directives.
• AddCratisOrleans* entry points are now AddCratisChoreography* (for example AddCratisChoreographyMongoDBJobsStorage), and CratisOrleansOptions is now CratisChoreographyOptions.
• Every grain interface and Orleans codec carries its new full name on the wire, so silos running 1.x and 2.x cannot share a cluster. Upgrade all silos of a cluster together; a rolling upgrade across this release is not supported.
• Stored state keeps its existing identifiers: the [GrainType] names, the workflow journal grain id, the workflow wake reminder name and the SQL migration id are unchanged, so existing grain state, reminders and migration history still resolve.
• The repository moves to https://github.com/Cratis/Choreography and the documentation to https://www.cratis.io/choreography/.

Release v1.34.0

Jobs with very many steps, such as large catch-up jobs, now keep their step plan outside the job document. One known limitation remains: a job can still stall if the acknowledgement of its Running write is lost. A reconciliation sweep for that is tracked in #177.

Added

• Job storage gains IJobStepPlanStorage, so storage providers can keep a job's planned steps outside the job state document. The MongoDB provider stores them in their own collection, in bounded batches (#172)

Fixed

• Jobs with very many steps no longer exceed MongoDB's 16 MB document limit and fail to start. A stored step plan is removed only after the job reaches a final state or is removed, and a job started again with the same id never loads or deletes the plan of an earlier run

Release v1.33.1

Fixed

• Cratis.Orleans.Chronicle depends on Cratis.Chronicle 19.114.0 or later again, instead of 19.115.2. Applications can stay on Chronicle 19.114 while 19.115 has startup problems with hosts that never call WithTelemetry (Cratis/Chronicle#5492) and with integration hosts using Chronicle.Testing (Cratis/Chronicle#5527)

Release v1.33.0

Cratis.Orleans now includes a durable, grain-based workflow engine. A workflow is a graph defined as data that runs as a durable process: each run rebuilds its state from its own journal of facts when it activates, so it survives silo restarts and moves between silos.

Added

• Workflow engine in Cratis.Orleans: a graph of Trigger, Action, Decision, Wait, Approval, ForEach and Join nodes with named outlets and per-node retry policy, versioned definitions with admission policies, run and workflow grains, and node work executed as jobs. (#167)
• IWorkflowRunJournal, with a journal on Orleans grain storage so workflows run without Chronicle.
• A sweep and a per-run timer and reminder, so waits and retries resume after a restart.
• AddCratisOrleansWorkflows() and CratisOrleansOptions.Workflows to host workflows.
• CratisOrleansOptions.Local(), a database-free configuration with localhost clustering and in-memory grain storage, for development and embedded hosts.
• Chronicle adapter in Cratis.Orleans.Chronicle: an event-sourced journal, event, state-machine, schedule and manual triggers, signals, run listing and open-wait read models, and AddEventSourcedWorkflows().
• Documentation for workflows: https://github.com/Cratis/Orleans/blob/main/Documentation/concepts/workflows.md

Release v1.32.3

Fixed

• Due step retries now wait until a job's resume hook has succeeded in the current activation, instead of running while the hook is still owed. Held retries keep their attempts and are not counted as failures; once the hook succeeds, overdue retries run immediately. Stopping or removing the job still records pending retries as failures. (#161)

Release v1.32.2

Fixed

• Recover previously stopped job steps when retrying a failed resume after an incomplete stop, while preserving live outcomes, execution generation, stage barriers, and concurrency limits. (#159)

Release v1.32.1

Fixed

• Jobs whose stored request is missing are no longer silently admitted when admission policies are registered. Start and Resume now report Unknown without changing the job, and a later stage keeps waiting and retrying, instead of running work that no policy approved. Without registered policies, such jobs still run as before. (#162)

Release v1.32.0

Changed

• After a job grain is reactivated, a stage that completes before OnBeforeResumingJobSteps has succeeded no longer starts the next stage, and the job does not complete while that stage waits. The watchdog's resume runs the hook and then starts the held stage. With the watchdog turned off, cold activations keep advancing stages as before. (#157)

Fixed

• A job interrupted while preparing or starting its steps whose OnBeforeResumingJobSteps throws no longer stays in PreparingSteps or StartingSteps with nothing retrying it. The watchdog now retries the resume with the same growing back-off as for Running jobs until startup finishes. (#157)

Release v1.31.0

Added

• IJob.ResumeIfRunning() and IJobsManager.ResumeIfRunning(JobId) resume a job only while it is still Running. The status is checked inside the job grain's own turn, so an operator Stop or Remove can never land between the check and the resume. A job in any other status is left untouched and the call returns the new ResumeJobSuccess.JobIsNotRunning. Resume() stays unrestricted. Both interfaces move to [Version(1)], so during a rolling upgrade calls to the new methods go to silos running this version. (#155)

Changed

• A job resumed while it sits between two stages now runs OnBeforeResumingJobSteps before starting the next stage, like every other resume path. (#155)
• While a job activation's resume hook has not succeeded, the window fill and the restart of steps whose owner is gone start no steps. A cold Running activation resumes itself on its first watchdog tick, so it keeps working after the job grain is reactivated on another silo. With the watchdog turned off, cold activations keep dispatching as before. (#155)

Fixed

• A Running job whose OnBeforeResumingJobSteps throws no longer stays Running forever with nothing dispatched. The watchdog retries the resume with a growing back-off for as long as the job stays Running, and stops retrying once it is stopped or removed. (#155)