From d8cdc8911e6ee5190abf4d09719fd21aa0029c76 Mon Sep 17 00:00:00 2001 From: Hunter Achieng Date: Mon, 13 Oct 2025 16:35:27 +0300 Subject: [PATCH 1/5] feat: update cron trigger runs description Signed-off-by: Hunter Achieng --- docs/jobs/state.md | 36 ++++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/docs/jobs/state.md b/docs/jobs/state.md index 086d398f09d9..489cf626d3fa 100644 --- a/docs/jobs/state.md +++ b/docs/jobs/state.md @@ -148,10 +148,26 @@ The input state looks like this: ### Cron triggered runs -On the platform, when a Run is triggered by a cron job, the input state will the -final output state of the **last succesful run** for this workflow. This allows -each subsequent run to _know_ about previous runs—i.e., you can pass information -from one run to another even if they happen days apart. +#### What are cron jobs? + +A **cron job** is a time-based scheduler that automatically runs your workflow at specified intervals. Think of it like setting an alarm clock for your workflow. It will run automatically at the times you configure, whether that's every hour, daily at 9 AM, or on the first day of each month. + +Common cron job examples: +- **Daily sync**: Pull new records from a database every day at midnight +- **Weekly reports**: Generate and send reports every Friday at 5 PM +- **Hourly monitoring**: Check system status every hour during business hours +- **Monthly cleanup**: Archive old data on the first day of each month + +#### Default input for cron workflows + +When a workflow has a **cron trigger**, it will automatically use a default input for its scheduled runs. On the platform, this appears as: + +> **Default Next Input for Cron** +> This workflow has a "cron" trigger, and by default it will use the input below for its next run. You can override that by starting a manual run with an empty input or a custom input at any time. + +#### How cron input state works + +When a run is triggered by a cron job, the input state will be the final output state of the **last successful run** for this workflow. This allows each subsequent run to _know_ about previous runs. In other words, you can pass information from one run to another even if they happen days apart. ```js { @@ -159,8 +175,16 @@ from one run to another even if they happen days apart. } ``` -If this is the first time the workflow has run, the initial state will simply by -an empty Javascript object: `{}` +**Example scenario**: If your workflow fetches new records and the last run processed records up to ID 1000, the next cron run will start with that information and can fetch records starting from ID 1001. + +If this is the first time the workflow has run, the initial state will simply be an empty JavaScript object: `{}` + +#### Overriding cron input + +You can always **manually run** a cron-triggered workflow with: +- **Empty input**: `{}` - starts fresh without previous state +- **Custom input**: Your own data to test specific scenarios +- **Default input**: Uses the same input as the scheduled runs ## Input & output state for steps From e20ed382977852e8958c3805fc9ebc5721f169f3 Mon Sep 17 00:00:00 2001 From: Hunter Achieng Date: Mon, 13 Oct 2025 21:51:55 +0300 Subject: [PATCH 2/5] fix: update docs Signed-off-by: Hunter Achieng --- docs/jobs/state.md | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/docs/jobs/state.md b/docs/jobs/state.md index 489cf626d3fa..f2318e82523e 100644 --- a/docs/jobs/state.md +++ b/docs/jobs/state.md @@ -152,18 +152,6 @@ The input state looks like this: A **cron job** is a time-based scheduler that automatically runs your workflow at specified intervals. Think of it like setting an alarm clock for your workflow. It will run automatically at the times you configure, whether that's every hour, daily at 9 AM, or on the first day of each month. -Common cron job examples: -- **Daily sync**: Pull new records from a database every day at midnight -- **Weekly reports**: Generate and send reports every Friday at 5 PM -- **Hourly monitoring**: Check system status every hour during business hours -- **Monthly cleanup**: Archive old data on the first day of each month - -#### Default input for cron workflows - -When a workflow has a **cron trigger**, it will automatically use a default input for its scheduled runs. On the platform, this appears as: - -> **Default Next Input for Cron** -> This workflow has a "cron" trigger, and by default it will use the input below for its next run. You can override that by starting a manual run with an empty input or a custom input at any time. #### How cron input state works @@ -182,9 +170,10 @@ If this is the first time the workflow has run, the initial state will simply be #### Overriding cron input You can always **manually run** a cron-triggered workflow with: -- **Empty input**: `{}` - starts fresh without previous state -- **Custom input**: Your own data to test specific scenarios -- **Default input**: Uses the same input as the scheduled runs +- **Empty input**: `{}` - starts fresh without previous state. + - If your manual run succeeds, the next scheduled cron run will start with whatever output state your manual run produced. +- **Custom input**: Your own data to test specific scenarios. +- **Default input**: Uses the same input as the scheduled runs. ## Input & output state for steps From c39511044a21331608b7de71b5d6db78456a6b5c Mon Sep 17 00:00:00 2001 From: Hunter Achieng Date: Tue, 14 Oct 2025 12:36:19 +0300 Subject: [PATCH 3/5] fix cron description Signed-off-by: Hunter Achieng --- docs/jobs/state.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/jobs/state.md b/docs/jobs/state.md index f2318e82523e..b6f54238f7b4 100644 --- a/docs/jobs/state.md +++ b/docs/jobs/state.md @@ -155,11 +155,11 @@ A **cron job** is a time-based scheduler that automatically runs your workflow a #### How cron input state works -When a run is triggered by a cron job, the input state will be the final output state of the **last successful run** for this workflow. This allows each subsequent run to _know_ about previous runs. In other words, you can pass information from one run to another even if they happen days apart. +When a run is triggered by a cron job, the input state will be the final output state of the **last successful run** of the first step in the workflow. This allows each subsequent run to _know_ about previous runs. In other words, you can pass information from one run to another even if they happen days apart. ```js { - ...finalStateOfLastSuccessfulRun, + ...finalStateOfLastSuccessfulRunOfStep1, } ``` From aecba46eafcae9b3f1e6f69cbaf0d2e51803a67d Mon Sep 17 00:00:00 2001 From: Hunter Achieng Date: Tue, 28 Oct 2025 20:31:01 +0300 Subject: [PATCH 4/5] fix: update the cron docs Signed-off-by: Hunter Achieng --- docs/jobs/state.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/jobs/state.md b/docs/jobs/state.md index b6f54238f7b4..73b6e5fe4499 100644 --- a/docs/jobs/state.md +++ b/docs/jobs/state.md @@ -163,15 +163,14 @@ When a run is triggered by a cron job, the input state will be the final output } ``` -**Example scenario**: If your workflow fetches new records and the last run processed records up to ID 1000, the next cron run will start with that information and can fetch records starting from ID 1001. +**Example scenario**: You have a **daily sync at 9 AM** with a workflow that has 3 steps: (1) fetch patient records, (2) transform data, (3) send to database. On Monday, the **first step** processes records up to ID 1000 and outputs `{ lastProcessedId: 1000 }`. Even though steps 2 and 3 modify the state further, only the **first step's output** gets saved for the next cron run. On Tuesday at 9 AM, the cron job starts again with `{ lastProcessedId: 1000 }` from Monday's first step, so it knows to fetch records starting from ID 1001. If this is the first time the workflow has run, the initial state will simply be an empty JavaScript object: `{}` #### Overriding cron input -You can always **manually run** a cron-triggered workflow with: +You can always manually run a cron-triggered workflow with: - **Empty input**: `{}` - starts fresh without previous state. - - If your manual run succeeds, the next scheduled cron run will start with whatever output state your manual run produced. - **Custom input**: Your own data to test specific scenarios. - **Default input**: Uses the same input as the scheduled runs. From 1780c0f8c96135d765ad557e4f280311e15f7cc4 Mon Sep 17 00:00:00 2001 From: Joe Clark Date: Mon, 17 Nov 2025 10:27:21 +0000 Subject: [PATCH 5/5] edit --- docs/jobs/state.md | 21 +++++---------------- 1 file changed, 5 insertions(+), 16 deletions(-) diff --git a/docs/jobs/state.md b/docs/jobs/state.md index 73b6e5fe4499..165b6949e1b4 100644 --- a/docs/jobs/state.md +++ b/docs/jobs/state.md @@ -87,7 +87,7 @@ fn(state => { return state; }); -// cleanup state at the end before finshing job +// cleanup state at the end before finishing job fn(state => { state.data = null state.users = null @@ -148,24 +148,11 @@ The input state looks like this: ### Cron triggered runs -#### What are cron jobs? - -A **cron job** is a time-based scheduler that automatically runs your workflow at specified intervals. Think of it like setting an alarm clock for your workflow. It will run automatically at the times you configure, whether that's every hour, daily at 9 AM, or on the first day of each month. - - -#### How cron input state works - -When a run is triggered by a cron job, the input state will be the final output state of the **last successful run** of the first step in the workflow. This allows each subsequent run to _know_ about previous runs. In other words, you can pass information from one run to another even if they happen days apart. - -```js -{ - ...finalStateOfLastSuccessfulRunOfStep1, -} -``` +When a run is triggered by a cron job, its input state will be the output of the **first step** from the previous run. This allows each subsequent run to know about previous runs. In other words, you can pass information from one run to another even if they happen days apart. **Example scenario**: You have a **daily sync at 9 AM** with a workflow that has 3 steps: (1) fetch patient records, (2) transform data, (3) send to database. On Monday, the **first step** processes records up to ID 1000 and outputs `{ lastProcessedId: 1000 }`. Even though steps 2 and 3 modify the state further, only the **first step's output** gets saved for the next cron run. On Tuesday at 9 AM, the cron job starts again with `{ lastProcessedId: 1000 }` from Monday's first step, so it knows to fetch records starting from ID 1001. -If this is the first time the workflow has run, the initial state will simply be an empty JavaScript object: `{}` +The first time the workflow runs, the initial state will simply be an empty JavaScript object: `{}` #### Overriding cron input @@ -174,6 +161,8 @@ You can always manually run a cron-triggered workflow with: - **Custom input**: Your own data to test specific scenarios. - **Default input**: Uses the same input as the scheduled runs. +If the manual run succeeds, the next scheduled cron run will start with whatever output state your manual run produced. + ## Input & output state for steps State is also passed between each step in a workflow. The output state of the