Skip to content

Commit 6e45f91

Browse files
Workflows: Multiple minor updates and fixes (#20035)
* Multiple minor updates * Update src/content/docs/workflows/build/sleeping-and-retrying.mdx Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com> --------- Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com>
1 parent 84ba456 commit 6e45f91

File tree

3 files changed

+8
-6
lines changed

3 files changed

+8
-6
lines changed

src/content/docs/workflows/build/sleeping-and-retrying.mdx

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -26,7 +26,7 @@ Use `step.sleep` to have a Workflow sleep for a relative period of time:
2626
await step.sleep("sleep for a bit", "1 hour")
2727
```
2828

29-
The second argument to `step.sleep` accepts both `number` (seconds) or a human-readable format, such as "1 minute" or "26 hours". The accepted units for `step.sleep` when used this way are as follows:
29+
The second argument to `step.sleep` accepts both `number` (milliseconds) or a human-readable format, such as "1 minute" or "26 hours". The accepted units for `step.sleep` when used this way are as follows:
3030

3131
```ts
3232
| "second"
@@ -48,7 +48,7 @@ const workflowsLaunchDate = Date.parse("24 Oct 2024 13:00:00 UTC");
4848
await step.sleepUntil("sleep until X times out", workflowsLaunchDate)
4949
```
5050

51-
You can also provide a Unix timestamp (seconds since the Unix epoch) directly to `sleepUntil`.
51+
You can also provide a UNIX timestamp (milliseconds since the UNIX epoch) directly to `sleepUntil`.
5252

5353
## Retry steps
5454

@@ -69,7 +69,7 @@ const defaultConfig: WorkflowStepConfig = {
6969

7070
When providing your own `StepConfig`, you can configure:
7171

72-
* The total number of attempts to make for a step
72+
* The total number of attempts to make for a step (accepts `Infinity` for unlimited retries)
7373
* The delay between attempts (accepts both `number` (ms) or a human-readable format)
7474
* What backoff algorithm to apply between each attempt: any of `constant`, `linear`, or `exponential`
7575
* When to timeout (in duration) before considering the step as failed (including during a retry attempt)

src/content/docs/workflows/build/trigger-workflows.mdx

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -144,14 +144,14 @@ Calling `resume` on an instance that is not currently paused will have no effect
144144

145145
### Stop a Workflow
146146

147-
You can stop a Workflow instance by calling `abort` against a specific instance ID.
147+
You can stop/terminate a Workflow instance by calling `terminate` against a specific instance ID.
148148

149149
```ts
150150
let instance = await env.MY_WORKFLOW.get("abc-123")
151-
await instance.abort() // Returns Promise<void>
151+
await instance.terminate() // Returns Promise<void>
152152
```
153153

154-
Once stopped, the Workflow instance *cannot* be resumed.
154+
Once stopped/terminated, the Workflow instance *cannot* be resumed.
155155

156156
### Restart a Workflow
157157

src/content/docs/workflows/build/workers-api.mdx

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -47,6 +47,8 @@ The `WorkflowEvent` type accepts an optional [type parameter](https://www.typesc
4747

4848
Refer to the [events and parameters](/workflows/build/events-and-parameters/) documentation for how to handle events within your Workflow code.
4949

50+
Finally, any JS control-flow primitive (if conditions, loops, try-catches, promises, etc) can be used to manage steps inside the `run` method.
51+
5052
## WorkflowEvent
5153

5254
```ts

0 commit comments

Comments
 (0)