Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Extract datetime descriptor #974

Merged
merged 3 commits into from
Aug 16, 2024
Merged

Extract datetime descriptor #974

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
dfecc74
refactor: extract datetime descriptor
matthias-pichler Aug 15, 2024
5fcf8de
refactor: rename epoch fields
matthias-pichler Aug 15, 2024
a65ef0c
Merge branch 'main' into matthias-pichler/rename-datetimedescriptor-966
matthias-pichler Aug 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 21 additions & 17 deletions dsl.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -302,10 +302,27 @@ This argument contains information about the runtime executing the workflow.
|:-----|:----:|:------------|:--------|
| id | `string` | A unique id of the workflow execution. Now specific format is imposed | UUIDv4: `4a5c8422-5868-4e12-8dd9-220810d2b9ee`, ULID: `0000004JFGDSW1H037G7J7SFB9` |
| definition | `map` | The workflow's definition as a parsed object | `{ "document": { ... }, "do": [...] }` |
| input | `any` | The workflow's *raw* input (i.e *BEFORE* the `input.from` expression). For the result of `input.from` expression use the `$input` argument | - |
| startedAt.iso8601 | `string` | The start time of the execution as a ISO 8601 date time string. It uses `T` as the date-time delimiter, either UTC (`Z`) or a time zone offset (`+01:00`). The precision can be either seconds, milliseconds or nanoseconds | `2022-01-01T12:00:00Z`, `2022-01-01T12:00:00.123456Z`, `2022-01-01T12:00:00.123+01:00` |
| startedAt.epochMillis | `integer` | The start time of the execution as a integer value of milliseconds since midnight of 1970-01-01 UTC | `1641024000123` (="2022-01-01T08:00:00.123Z") |
| startedAt.epochNanos | `integer` | The start time of the execution as a integer value of nanoseconds since midnight of 1970-01-01 UTC | `1641024000123456` (="2022-01-01T08:00:00.123456Z") |
| input | `any` | The workflow's *raw* input (i.e *BEFORE* the `input.from` expression). For the result of `input.from` expression use the `$input` argument | |
| startedAt | [`dateTimeDescriptor`](#datetime-descriptor) | The start time of the execution | |

##### Task Descriptor

| Name | Type | Description | Example |
|:-----|:----:|:------------|:--------|
| name | `string` | The task's name. | `getPet` |
| reference | `string` | The task's reference. | `/do/2/myTask` |
| definition | `map` | The tasks definition (specified under the name) as a parsed object | `{ "call": "http", "with": { ... } }` |
| input | `any` | The task's *raw* input (i.e. *BEFORE* the `input.from` expression). For the result of `input.from` expression use the context of the runtime expression (for jq `.`) | |
| output | `any` | The task's *raw* output (i.e. *BEFORE* the `output.as` expression). | |
| startedAt | [`dateTimeDescriptor`](#datetime-descriptor) | The start time of the task | |

##### DateTime Descriptor

| Name | Type | Description | Example |
|:-----|:----:|:------------|:--------|
| iso8601 | `string` | The date time as a ISO 8601 date time string. It uses `T` as the date-time delimiter, either UTC (`Z`) or a time zone offset (`+01:00`). The precision can be either seconds, milliseconds or nanoseconds | `2022-01-01T12:00:00Z`, `2022-01-01T12:00:00.123456Z`, `2022-01-01T12:00:00.123+01:00` |
| epoch.sec | `integer` | The date time as a integer value of seconds since midnight of 1970-01-01 UTC (i.e. [the Unix Epoch](https://en.wikipedia.org/wiki/Unix_time)) | `1641024000` (="2022-01-01T08:00:00Z") |
cdavernas marked this conversation as resolved.
Show resolved Hide resolved
| epoch.ms | `integer` | The date time as a integer value of milliseconds since midnight of 1970-01-01 UTC. This contains the *whole* timestamp, not just the millisecond portion | `1641024000123` (="2022-01-01T08:00:00.123Z") |

The following table shows which arguments are available for each runtime expression:

Expand All @@ -319,19 +336,6 @@ The following table shows which arguments are available for each runtime express
| Task `export.as` | Transformed task output | `$context` | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Workflow `output.as` | Last task's transformed output | Transformed workflow output | ✔ | | | ✔ | | ✔ |

##### Task Descriptor

| Name | Type | Description | Example |
|:-----|:----:|:------------|:--------|
| name | `string` | The task's name. | `getPet` |
| reference | `string` | The task's reference. | `/do/2/myTask` |
| definition | `map` | The tasks definition (specified under the name) as a parsed object | `{ "call": "http", "with": { ... } }` |
| input | `any` | The task's *raw* input (i.e. *BEFORE* the `input.from` expression). For the result of `input.from` expression use the context of the runtime expression (for jq `.`) | - |
| output | `any` | The task's *raw* output (i.e. *BEFORE* the `output.as` expression). | - |
| startedAt.iso8601 | `string` | The start time of the task as a ISO 8601 date time string. It uses `T` as the date-time delimiter, either UTC (`Z`) or a time zone offset (`+01:00`). The precision can be either seconds, milliseconds or nanoseconds | `2022-01-01T12:00:00Z`, `2022-01-01T12:00:00.123456Z`, `2022-01-01T12:00:00.123+01:00` |
| startedAt.epochMillis | `integer` | The start time of the task as a integer value of milliseconds since midnight of 1970-01-01 UTC | `1641024000123` (="2022-01-01T08:00:00.123Z") |
| startedAt.epochNanos | `integer` | The start time of the task as a integer value of nanoseconds since midnight of 1970-01-01 UTC | `1641024000123456` (="2022-01-01T08:00:00.123456Z") |

### Fault Tolerance

Serverless Workflow is designed with resilience in mind, acknowledging that errors are an inevitable part of any system. The DSL provides robust mechanisms to identify, describe, and handle errors effectively, ensuring the workflow can recover gracefully from failures.
Expand Down
Loading