All versions since 2.7.0

2.7.0

Oct 14, 2026

API version: 10.5.0

Jobs show when they were scheduled for execution as ScheduledAt, next to CreatedAt, StartedAt and CompletedAt: the UTC time the Job moved from ReadyForProcessing to Pending. It is recorded once and does not change afterwards. StartedAt minus ScheduledAt is the time a Job waited for a worker, while StartedAt minus CreatedAt also counts the time it spent being configured before it was scheduled. Jobs that started before this release get their CreatedAt as ScheduledAt (their StartedAt if that is earlier), so their wait reads as before. Other Jobs scheduled before this release, and Jobs not scheduled yet, have no ScheduledAt; the property is then absent.

Oct 14, 2026

API version: 11.0.0

The statistics, now at GET api/Statistics/Query (see Changed), answer more numbers; every earlier field and parameter keeps its meaning. WorkDataPerUser and WorkDataPerKind split all WorkData of the Owner by creating user and by kind, each with Count and UsedStorageInBytes. Each CompletionDays entry also has ComputeMs, the summed run time of the day’s Completed and failed Jobs that have a start time; TimeToStartP50Ms and TimeToStartP90Ms, how long those Jobs waited from ScheduledAt to their start (absent without a Job that has both); and ProducedBytes, the size of the WorkData they produced through their output slots. UploadDays has an entry for every UTC day from UploadedFrom (default: today) with an upload: the UploadedBytes of the WorkData uploaded that day. ProcessingSteps counts the Jobs that ended from ProcessingStepsFrom (default: today) per ProcessingStep function across its versions: Title (of the step the latest of them ran), Completed, Failed, and the p50 and p90 run time of the Completed ones in milliseconds. Hidden items and sub-jobs count. Both new days may start at most 366 days back, and the CreateStatisticsQuery action takes them too.

GET api/Statistics is now the Statistics Root, linked from the entry point as StatisticsRoot in place of Statistics: it computes nothing and carries the CreateStatisticsQuery action, which rejects a window that starts more than 366 days back with 400 when it is submitted, not when its Location is followed. The statistics moved to GET api/Statistics/Query, with the same query parameters; the action’s Location points there. They no longer carry the action, and they name the windows they cover, defaults filled in: CreatedAfter, CompletedFrom, UploadedFrom and ProcessingStepsFrom. Clients that read the statistics by URL move to GET api/Statistics/Query.

Oct 15, 2026

API version: 11.0.1

The CreateStatisticsQuery action of the Statistics Root is prefilled with the current default windows, so a form generated from it shows them instead of empty fields. Submitting the prefilled values fixes them in the query; omit a window to keep it rolling.
Renaming or moving a folder onto the name of an existing sibling answers 423 instead of 500 (#196): the foundation library now maps a unique violation from raw SQL like one from SaveChanges. A database that refuses connections or is in recovery is likewise reported as temporarily unavailable instead of as an internal error.

Oct 17, 2026

API version: 11.0.1

A tag value is a timestamp only in ISO 8601 form, as documented: it must start with a yyyy-MM-dd date. Other text that .NET reads as a date is a string now. A version like Version=1.7.0 was taken for 2000-01-07 and rejected with 400 “Detected timestamp without defining time zone”, as were values like 2.8.1, 10/16/2026, Jan 2026 or 4/3. With a Z or an offset, such a value was stored as a timestamp instead. Versions starting with 0. were not affected. A typed query value {timestamp:...} follows the same rule and rejects any other value as an invalid timestamp. Tag value types also no longer depend on the server’s culture. Tags already stored keep their type. Present since 20260130.205.

Oct 19, 2026

API version: 11.1.0

A deployment can state its resources explicitly (#229). The ConfigureDeployment action of a ProcessingStep takes Resources with CpuMillicores, MemoryMiB and DiskGiB, as an alternative to ResourcePreset. A request passes exactly one of the two, otherwise it gets 400. A preset stands for the resources the operator applied for it so far, from XSmall (250 millicores, 512 MiB, 3 GiB) to XXLarge (14000 millicores, 60416 MiB, 300 GiB), so clients that send only ResourcePreset keep working unchanged. The deployment shows CpuMillicores, MemoryMiB and DiskGiB, and ResourcePreset when the values are exactly those of a preset, otherwise null. The action’s prefilled values carry only one of the two: the preset when the resources match one, otherwise the resources.
Resources above the resource ceiling are rejected with 400, whether stated explicitly or through a preset; the operator would silently cut them down. The ceiling is set in Deployment:MaxResources (CpuMillicores, MemoryMiB, DiskGiB) and defaults to one ccx43 peak node: 15400 millicores, 60416 MiB and 325 GiB. Set it to the operator’s job.maxResources.* of the namespace when they differ.

The deployment message to the operator carries spec.resources (cpu, memory, disk as Kubernetes quantities, e.g. "500m", "1024Mi", "10Gi") and no longer spec.resourcePreset. This needs operator 0.3.0 or later; deploy that first. After this release, re-apply every existing deployment so its StepFunction gets explicit resources.
Existing deployments are migrated to the resources of their preset; the stored preset is dropped.