Skip to content
PineXQ LogoPineXQ Documentation

All versions since 2.2.0

All versions

2.2.0

API version: 10.1.0

Added

  • UploadWorkData can file the new WorkData into a folder, tag it and mark it secret, all in the commit that creates it (issue #179). Before, each took a follow-up call (MoveToFolder, SetTags, MarkAsSecret), and a client failing between them left the WorkData in the root, untagged or not secret. The properties go in an optional form field UploadWorkDataParameters holding {"Folder": <folder URL>, "Tags": [...], "Secret": true} (every member optional), before or after the file. Sent before the file, an unknown or foreign folder or an invalid tag fails the upload before any content is stored; sent after it, the stored content is removed again. The upload still streams the file without buffering it. The SIREN Upload action of the WorkData root lists the new field (class FileUploadActionWithParameter) and keeps the class FileUploadAction, so existing clients continue to work. Without the field an upload behaves as before.

Fixed

  • Setting a WorkData’s tags with a null tag ({"Tags":[null]}) failed with HTTP 500 instead of a validation error (400).

2.2.1

API version: 10.1.0

Fixed

  • The Gitea release has the generated openapi.json attached again. Every release since the switch to semantic versioning shipped without it.

2.3.0

API version: 10.1.1

Changed

  • An output slot without a target folder now files its produced WorkData into the Job’s folder instead of the Owner’s root. The folder is the one the Job is in when it is scheduled; a Job at the root still writes its outputs to the root. Once a Job is scheduled, moving it does not move its outputs; a retry after a failed scheduling attempt files the already prepared outputs into the Job’s current folder. An explicit target set with SetOutputFolder still takes precedence. This includes sub-jobs created with InheritParentFolder: they sit in the parent’s folder, so their untargeted outputs now land there too.
  • SetOutputFolder with / now pins the output slot to the Owner’s root, so an output of a Job in a folder can still go to the root. Previously / cleared the target like an empty path; an empty path still clears it, and the slot then follows the Job’s folder. A / sent before this change was stored as no target, so such a slot of a not yet scheduled Job now follows the Job’s folder as well.

Fixed

  • DeleteJob checks that the caller may access the Job (issue #197). Any user with a plan grant could delete another Owner’s Job by its id, across tenants, as long as the Job was not running and had no output WorkData. Now only the Job’s Owner or an admin can delete it; anyone else gets 403. The check runs before the sub-job check, so a caller without access no longer sees the ids of the Job’s sub-jobs in the error. Present since job deletion was added in 2024.
  • Creating a sub-job checks that the caller may access the parent Job (issue #198), through CreateSubJob and through RapidJobSetup with a ParentJobUrl. Any user with a plan grant could attach a sub-job to another Owner’s pending or processing Job; that Owner could then no longer delete their Job, and with InheritParentFolder the sub-job carried their folder. Now only the parent’s Owner or an admin can create a sub-job under it; anyone else gets 403. Workers are unaffected: they act as the identity that scheduled the parent, which already passes the same check when reading the Job.

2.4.0

API version: 10.2.0

Added

  • Action templates and cron triggers can be filed in folders, like Jobs, WorkData and ProcessingSteps. Both have a MoveToFolder action (omit the folder to move back to the root), a FolderPath property and a ParentFolder link. CreateActionTemplate and CreateCronTrigger take an optional Folder to create the item directly in a folder. Filing only organizes the item: a template’s own folder does not decide where its jobs go, and a trigger’s schedule and linked templates are unchanged. A trigger and the templates it runs are filed independently.
  • Action templates have a job folder: SetJobFolder sets the folder that jobs created from the template (by a trigger or ExecuteNow) are filed into, shown as JobFolder. It is a path, like an output slot target: the folder, and any missing folders above it, are created when a job is created, under the job’s owner, and renaming or moving the folder does not update the setting. Their outputs then follow the job’s folder. An empty path or / clears it, and jobs are created at the root as before; unlike an output slot, an unset job folder does not fall back to the template’s own folder.
  • The template and trigger queries take the Folder/FolderRecursive filter of the other foldable queries.
  • Folder contents list templates and triggers next to Jobs, WorkData and ProcessingSteps, as ActionTemplate and CronJobTrigger entities. Clients that only know the earlier types can skip them; the total count includes them.
  • The folder children Contains filter accepts actiontemplate and actiontrigger.

Changed

  • DeleteFolder also refuses a folder that holds templates or triggers.
  • The folder Clear action also deletes the templates and triggers in the folder and its descendant folders. It deletes triggers first, then templates, then Jobs, ProcessingSteps and WorkData. Deleting a template unlinks it from every trigger, including triggers outside the folder. The report lists them with the item types ActionTrigger and ActionTemplate.

2.5.0

API version: 10.3.0

Added

  • GET api/Statistics, linked from the entry point as Statistics: the caller’s Owner’s numbers, aggregated by the database instead of paged through item by item. WorkDataCount, UsedStorageInBytes and DeployedProcessingStepCount (the Owner’s own steps deployed on the platform and not deprecated) are totals. JobsCreatedPerUser counts the Jobs created after CreatedAfter (default: 24 hours ago) per creating user. CompletionDays has an entry for every UTC day from CompletedFrom (default: today) on which a Job ended: its Completed and Failed (Error) Jobs, the p50 and p90 run time of the Completed ones in milliseconds, and their count per ProcessingStep function. Hidden Jobs and sub-jobs count. Either window may start at most 366 days back. The resource’s CreateStatisticsQuery action, prefilled with its own windows, answers 201 with the statistics of other windows as Location.

2.6.0

API version: 10.4.0

Added

  • An action template’s job folder can contain date placeholders, filled in each time a job is created from the template (by a trigger or ExecuteNow): {{date}}, {{date+N}} or {{date-N}} (N days, at most 365), each optionally followed by @ and a time zone, the IDs cron triggers accept. SetJobFolder with /reports/{{date+1@Europe/Berlin}}/ files a job created at 00:30 on 2026-10-14 in Berlin into /reports/2026-10-15/. Without a time zone the date is UTC. Dates are always written as yyyy-MM-dd. A placeholder may stand alone as a folder name or inside one, and a path may hold several. JobFolder shows the path as written. SetJobFolder refuses an unknown placeholder, an offset beyond 365 days, an unknown time zone, or a path that would not be valid once filled in. Job folders set before keep their meaning: braces were never allowed in folder names.

2.7.0

API version: 10.5.0

Added

  • 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.

2.8.0

API version: 11.0.0

Added

  • 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.

Changed

  • 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.

2.8.1

API version: 11.0.1

Fixed

  • 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.

2.8.2

API version: 11.0.1

Fixed

  • 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.

2.9.0 Latest

API version: 11.1.0

Added

  • 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.

Changed

  • 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.

PineXQ is a data cybernetics project

© 2026 data cybernetics ssc GmbH. All Rights Reserved.