how would I run a workflow when another workflow fails for whatever reason? - Cloudflare Developers

© 2026 Hedgehog Software, LLC

More

Communities Docs About Terms Privacy

johtso

J

johtsoOP•5/19/25, 3:09 PM

is there a concept of some kind of "finally" task?

johtso

Jjohtso how would I run a workflow when another workflow fails for whatever reason?

koraytaylan

K

koraytaylan•5/20/25, 7:58 AM

i think you could implement an abstract base class (which your actual workflow inherits) and then you could encapsulate the logic to capture error in this base class and add a message into a queue. then another worker would trigger and start that other workflow.

koraytaylan

Kkoraytaylan i think you could implement an abstract base class (which your actual workflow i...

johtso

J

johtsoOP•5/20/25, 8:01 AM

I don't think that works for the case of retry limits being reached

andifined.dev

Aandifined.dev Hey guys I‘ve got a question regardinhg sub request Limits within workflows: I...

koraytaylan

K

koraytaylan•5/20/25, 8:02 AM

it is interesting. i didn't know about such limitation. how about:
your current workflow would just be a proxy that adds those 600ids into a queue as 600 messages. then you could configure a worker that would trigger for those messages and create a separate workflow that only work for an individual image instead of trying to process all 600 in one workflow.

johtso

Jjohtso I don't think that works for the case of retry limits being reached

koraytaylan

K

koraytaylan•5/20/25, 8:10 AM

i have what i described in a simpler way to log detailed error messages on what went wrong. so, from the highest level if i am able catch an error and process it, then i guess it should be possible to trigger another workflow. now that i also realize you might not even need that queue because you could consider this part as a separate step to just trigger that other workflow.

koraytaylan

Kkoraytaylan i have what i described in a simpler way to log detailed error messages on what ...

johtso

J

johtsoOP•5/20/25, 8:13 AM

I'm thinking for example sending a customer an email if the order workflow terminates unsuccessful, and maybe refunding their payment. Catching errors doesn't let me know if the workflow was about to terminate / if there were still retries remaining. I could of course catch any unrecoverable errors, but that would still leave the retries exhausted case

koraytaylan

K

koraytaylan•5/20/25, 8:14 AM

i have an idea, i have been working with workflows and one thing that i keep thinking is how great it would be to have a tab called "Logs" inside workflow instance that displays

console.log

console.log

messages emitted during that workflow run.

johtso

Jjohtso I'm thinking for example sending a customer an email if the order workflow termi...

koraytaylan

K

koraytaylan•5/20/25, 8:17 AM

i believe there are two different scopes at play here. step scoped code gets retried when an error happens. but workflow scoped code does not have this. below is the abstract class i am talking about and the catch part here works only once.

`
export abstract class AbstractWorkflow<T, R> extends WorkflowEntrypoint<Env, T> {
  protected abstract getName(): string;
  protected abstract validateInput(input: T): void;
  protected abstract runStep(event: WorkflowEvent<T>, step: WorkflowStep): Promise<R>;

  async run(event: WorkflowEvent<T>, step: WorkflowStep): Promise<unknown> {
    console.log({
      message: `${this.getName()} started.`,
      level: "info",
      event,
    });
    try {
      this.validateInput(event.payload);
      const output = await this.runStep(event, step);
      console.log({
        message: `${this.getName()} completed.`,
        level: "info",
        event,
        output,
      });
      return output;
    } catch (error) {
      console.log({
        message: `${this.getName()} failed.`,
        level: "error",
        event,
        error,
      });
      throw error;
    }
  }
}

`
export abstract class AbstractWorkflow<T, R> extends WorkflowEntrypoint<Env, T> {
  protected abstract getName(): string;
  protected abstract validateInput(input: T): void;
  protected abstract runStep(event: WorkflowEvent<T>, step: WorkflowStep): Promise<R>;

  async run(event: WorkflowEvent<T>, step: WorkflowStep): Promise<unknown> {
    console.log({
      message: `${this.getName()} started.`,
      level: "info",
      event,
    });
    try {
      this.validateInput(event.payload);
      const output = await this.runStep(event, step);
      console.log({
        message: `${this.getName()} completed.`,
        level: "info",
        event,
        output,
      });
      return output;
    } catch (error) {
      console.log({
        message: `${this.getName()} failed.`,
        level: "error",
        event,
        error,
      });
      throw error;
    }
  }
}

koraytaylan

Kkoraytaylan it is interesting. i didn't know about such limitation. how about: your current...

andifined.dev

A

andifined.dev•5/20/25, 8:22 AM

But for my understanding that‘s the whole Point of using workflows. A Workflow has steps which get retried automatically on failure und I can define some Kind of process where each step depends on the steps before. So I don‘t unterstand why it‘s necessary to implement a workaround for functionality the product itself provides

Already implemented some Kind of workaround on my own to get around those Limits, but currently I‘m just waiting for Container compatibility because it‘s solving so much additional Problems I‘m having with workflows right know IMHO

andifined.dev

Aandifined.dev But for my understanding that‘s the whole Point of using workflows. A Workflow h...

koraytaylan

K

koraytaylan•5/20/25, 8:25 AM

i totally agree. what appealed me in the beginning was pretty much the point i could have code that can run for weeks if necessary. so it is for sure limiting to have only x amount of requests etc.

koraytaylan

Kkoraytaylan i believe there are two different scopes at play here. step scoped code gets ret...

johtso

J

johtsoOP•5/20/25, 9:25 AM

Do you know if reaching retry limit results in an error that can be caught? Also, if I run a "cleanup" step, and then rethrow the original error, will the workflow history correctly show the step as having failed?

johtso

J

johtsoOP•5/20/25, 10:50 AM

Awesome, it works exactly how I hoped it would! the workflow is marked as errored, but it also has a successful "cleanup" step after the errored step

Ben

B

Ben•5/20/25, 2:35 PM

Hello! I’m wondering if anyone else is running into a similar issue that we’re having. We’ve set up a workflow which has a waitForEventwaitForEvent step, but when we use sendEventsendEvent in our route to continue the workflow, we are sometimes waiting up to 45 minutes for the workflow to continue. Some extra info:

The route where sendEventsendEvent is being called is deployed to a Cloudflare Worker.
No errors are being thrown when sendEventsendEvent is called, and the types match.
The issue seems to happen when the workflow has been idle for at least 20 minutes, if the waitForEventwaitForEvent step has only been waiting for a few minutes I haven’t recreated the issue yet, but when the waitForEventwaitForEvent step has been waiting 20+ minutes we run into the issue the majority of the time.
We haven’t changed any of the default retry logic in the workflow.

Any ideas? My understanding is that this isn’t the expected behaviour in a Cloudflare Workflow.

johtso

J

johtsoOP•5/20/25, 2:55 PM

Are errors not recorded if they're in the top level of a workflow?

johtso

J

johtsoOP•5/20/25, 4:05 PM

how do I see logs from a workflow?

johtso

Jjohtso Are errors not recorded if they're in the top level of a workflow?

koraytaylan

K

koraytaylan•5/20/25, 5:21 PM

they show up in workflow instance details page but top level errors are not retried.

johtso

Jjohtso how do I see logs from a workflow?

koraytaylan

K

koraytaylan•5/20/25, 5:22 PM

you see them from the observability page where you track your worker logs also.

koraytaylan

Kkoraytaylan they show up in workflow instance details page but top level errors are not retr...

johtso

J

johtsoOP•5/20/25, 5:51 PM

they don't seem to appear on the workflow instance details page, the instance is marked as errored, but there are no steps to attach the error to so it isn't shown

johtso

J

johtsoOP•5/20/25, 5:51 PM

my solution was to wrap everything in a top level step with no retries

johtso

Jjohtso they don't seem to appear on the workflow instance details page, the instance is...

koraytaylan

K

koraytaylan•5/20/25, 5:54 PM

i am able to see the top level errors' messages on that page which i thought it would work the same for you sorry about that

koraytaylan

Kkoraytaylan i am able to see the top level errors' messages on that page which i thought it ...

johtso

J

johtsoOP•5/20/25, 5:59 PM

oh right, I do actually see something, but it just says "The execution of the Workflow instance was terminated, as a step threw an NonRetryableError and it was not handled"

johtso

J

johtsoOP•5/20/25, 5:59 PM

it doesn't give me the error's message

charl.dev

C

charl.dev•5/21/25, 8:12 PM

On my paid workers account, it seems I can’t deploy a worker with workflows. When I try publish the worker, the worker does get deployed but wrangler throws error for the ../workflows api.

Auth error

I also get an error if I try wrangler workflows list

charl.dev

C

charl.dev•5/21/25, 8:12 PM

I’ve tried logging in and out

charl.dev

C

charl.dev•5/21/25, 8:12 PM

Do I need to be enabled for workflows?

Boragorn

B

Boragorn•5/22/25, 1:45 AM

@moonage.dev not sure if this is what you're looking for, but that's how I deploy workers with workflows:

// src/workers/my.worker.ts

import { MyWorkflow } from "../workflows/my.workflow";

export {
   MyWorkflow
};


type Bindings = {
  MY_WORKFLOW: Workflow;
};

const app = new Hono<{ Bindings: Bindings }>();

app.post('/', async (c) => {
  return c.env.MY_WORKFLOW.create(..);
}) 

export default {
  fetch: app.fetch,
};

// src/workers/my.worker.ts

import { MyWorkflow } from "../workflows/my.workflow";

export {
   MyWorkflow
};


type Bindings = {
  MY_WORKFLOW: Workflow;
};

const app = new Hono<{ Bindings: Bindings }>();

app.post('/', async (c) => {
  return c.env.MY_WORKFLOW.create(..);
}) 

export default {
  fetch: app.fetch,
};

charl.dev

C

charl.dev•5/22/25, 6:30 AM

It’s not a problem with the worker, tried to deploy a fresh workflow starter and same issue:

workflows-starter2 % npm run deploy

workflows-starter@0.0.1 deploy
wrangler deploy

wrangler 4.16.0
-------------------

Total Upload: 2.20 KiB / gzip: 1.02 KiB
Your Worker has access to the following bindings:

Workflows:
- MY_WORKFLOW: MyWorkflow
  Uploaded workflows-starter2 (8.26 sec)

✘ [ERROR] A request to the Cloudflare API (/accounts/xxx/workflows/workflows-starter) failed.

Authentication error [code: 10000]

Getting User settings...

You are logged in with an OAuth Token, associated with the email xxx@gmail.com.
┌───────────────────────────────┬──────────────────────────────────┐
│ Account Name │ Account ID │
├───────────────────────────────┼──────────────────────────────────┤
│ xxx@gmail.com's Account │ xxx │
└───────────────────────────────┴──────────────────────────────────┘

Token Permissions: If scopes are missing, you may need to logout and re-login.
Scope (Access)

account (read)
user (read)
workers (write)
workers_kv (write)
workers_routes (write)
workers_scripts (write)
workers_tail (read)
d1 (write)
pages (write)
zone (read)
ssl_certs (write)
ai (write)
queues (write)
pipelines (write)
secrets_store (write)
offline_access
Membership roles in "xxx@gmail.com's Account": Contact account super admin to change your permissions.
Super Administrator - All Privileges

Stupefystar

S

Stupefystar•5/22/25, 6:33 AM

Can someone please tell me why my workflows are running multiples times in parallel?

export default {
    async fetch(req: Request, env: Env): Promise<Response> {
        let instance = await env.DATA_WORKFLOW.create();
        return Response.json({
            id: instance.id,
            details: await instance.status(),
        });
    },
};

export default {
    async fetch(req: Request, env: Env): Promise<Response> {
        let instance = await env.DATA_WORKFLOW.create();
        return Response.json({
            id: instance.id,
            details: await instance.status(),
        });
    },
};

I will have do something with idsdo something with ids run multiple times even tho it doesn't fail or anything

async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
        const storageKey = `instructions-${event.instanceId}.json`;
        const defaultConfig = {retries: { limit: 1, delay: 1000 }};

        try {
            const ids = await step.do('download ids', defaultConfig, async () => {
                //
            });

            await step.do('do something with ids', defaultConfig, async () => {
                //
            });

            await step.do('do something with ids', defaultConfig, async () => {
                //
            });

            // Cleanup after successful completion
            await this.env.TEMP_STORAGE.delete(storageKey);
        } catch (error) {
            // Cleanup on failure
            await this.env.TEMP_STORAGE.delete(storageKey);
            throw new NonRetryableError("Unknown error");
        }

        let workflow = await this.env.DATA_WORKFLOW.get(event.instanceId);
        await workflow.terminate();
    }

async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
        const storageKey = `instructions-${event.instanceId}.json`;
        const defaultConfig = {retries: { limit: 1, delay: 1000 }};

        try {
            const ids = await step.do('download ids', defaultConfig, async () => {
                //
            });

            await step.do('do something with ids', defaultConfig, async () => {
                //
            });

            await step.do('do something with ids', defaultConfig, async () => {
                //
            });

            // Cleanup after successful completion
            await this.env.TEMP_STORAGE.delete(storageKey);
        } catch (error) {
            // Cleanup on failure
            await this.env.TEMP_STORAGE.delete(storageKey);
            throw new NonRetryableError("Unknown error");
        }

        let workflow = await this.env.DATA_WORKFLOW.get(event.instanceId);
        await workflow.terminate();
    }

charl.dev

Ccharl.dev It’s not a problem with the worker, tried to deploy a fresh workflow starter and...

charl.dev

C

charl.dev•5/22/25, 6:35 AM

Magically working now to deploy

Original message was deleted

Stupefystar

S

Stupefystar•5/22/25, 9:19 AM

I simplified it for the demo, but each one has their own unique name.

Stupefystar

S

Stupefystar•5/22/25, 9:20 AM

ie first step runs this command where it runs 3 times all at once but this should only be run once.

Stupefystar

S

Stupefystar•5/22/25, 9:20 AM

Sometime it'll run once, sometimes three times

Stupefystar

S

Stupefystar•5/22/25, 9:59 AM

Stupefystar

S

Stupefystar•5/22/25, 9:59 AM

just within the closure of the first step

Stupefystar

S

Stupefystar•5/22/25, 10:57 AM

AHHH i am an idiot.. so because the web server is calling fetch(req: Request, env: Env): Promise<Response>fetch(req: Request, env: Env): Promise<Response> for the root, and the favicon requests that explains why each step is being called multiple times.

Wallslide

WWallslide Is it the env.WORKFLOW.create call that is failing? Is it in the workflow's run(...

Chaika

C

Chaika•5/22/25, 7:26 PM

nothing's failing, it's just the way workflow runs show in logs

Chaika

C

Chaika•5/22/25, 7:28 PM

team said they working on fixing workflows
https://discord.com/channels/595317990191398933/1303411588929294358/1303488051917492318

scook

S

scook•5/22/25, 11:50 PM

^ Does this mean there's an ongoing incident right now? Because some of my workflow invocations failed to call await env.WORKFLOW_NAME.create()await env.WORKFLOW_NAME.create() with an ambiguous "internal error", whereas some succeeded.

scook

S

scook•5/22/25, 11:58 PM

@Luís Duarte

Is there anything I can do to troubleshoot? We have certain invocations succeeding and others throwing "Error: internal error""Error: internal error" as far as I can tell.

Marco Aleixo

M

Marco Aleixo•5/23/25, 3:30 PM

[32mdetails:[0m { "request_id": "ae65c446-f13d-4f95-98b8-ed25ccfa47e6", "fileId": "a386a543-91f9-4a78-af85-257ee4ba2728", "error": "internal error", "stack": "Error: internal error\n at callFetcher (cloudflare-internal:workflows-api:24:15)\n at async WorkflowImpl.create (cloudflare-internal:workflows-api:78:24)\n at async fileUploadService (main.js:919559:11)\n at async fileUploadController (main.js:919663:32)\n at async dispatch (main.js:1116:21)\n at async main.js:859416:9\n at async dispatch (main.js:1116:21)\n at async main.js:859416:9\n at async dispatch (main.js:1116:21)\n at async main.js:967997:5" }",

[32mdetails:[0m { "request_id": "ae65c446-f13d-4f95-98b8-ed25ccfa47e6", "fileId": "a386a543-91f9-4a78-af85-257ee4ba2728", "error": "internal error", "stack": "Error: internal error\n at callFetcher (cloudflare-internal:workflows-api:24:15)\n at async WorkflowImpl.create (cloudflare-internal:workflows-api:78:24)\n at async fileUploadService (main.js:919559:11)\n at async fileUploadController (main.js:919663:32)\n at async dispatch (main.js:1116:21)\n at async main.js:859416:9\n at async dispatch (main.js:1116:21)\n at async main.js:859416:9\n at async dispatch (main.js:1116:21)\n at async main.js:967997:5" }",

When I start to get high traffic in an endpoint I'm starting to see errors above when trying to call a Workflow.
Seems to be something internal on CF side, the same code works fine when the traffic is "low"

And when I say high traffic, I'm saying something like 6 requests/s, in theory, this is supposed to be a low traffic on CF scale, right?

A

ac•5/24/25, 12:13 AM

Is it possible to get the number of times a workflow step has retried? I'd like to call some code on the final retry to prevent future jobs from picking up the same item.

I know I could technically keep it in a variable outside of the step but I worry that context would be lost on retries. Any options?

koraytaylan

K

koraytaylan•5/24/25, 3:39 PM

in workflow instance details page, output gets truncated for a particular "step history" which is a problem for me. i wonder if there is any plans to change this behavior?

Mr. Technician

M

Mr. Technician•5/24/25, 4:35 PM

I have a question the docs are not clear on:

// ✅ Good: steps that are dynamically named are constructed in a deterministic way.
    // In this case, `catList` is a step output, which is stable, and `catList` is
    // traversed in a deterministic fashion (no shuffles or random accesses) so,
    // it's fine to dynamically name steps (e.g: create a step per list entry).
    let catList = await step.do("get cat list from KV", async () => {
      return await env.KV.get("cat-list");
    });

    for (const cat of catList) {
      await step.do(`get cat: ${cat}`, async () => {
        return await env.KV.get(cat);
      });
    }

// ✅ Good: steps that are dynamically named are constructed in a deterministic way.
    // In this case, `catList` is a step output, which is stable, and `catList` is
    // traversed in a deterministic fashion (no shuffles or random accesses) so,
    // it's fine to dynamically name steps (e.g: create a step per list entry).
    let catList = await step.do("get cat list from KV", async () => {
      return await env.KV.get("cat-list");
    });

    for (const cat of catList) {
      await step.do(`get cat: ${cat}`, async () => {
        return await env.KV.get(cat);
      });
    }

Can I store the looped returned values? If so, how can I do so deterministically?

`
export abstract class AbstractWorkflow<T, R> extends WorkflowEntrypoint<Env, T> {
  protected abstract getName(): string;
  protected abstract validateInput(input: T): void;
  protected abstract runStep(event: WorkflowEvent<T>, step: WorkflowStep): Promise<R>;

  async run(event: WorkflowEvent<T>, step: WorkflowStep): Promise<unknown> {
    console.log({
      message: `${this.getName()} started.`,
      level: "info",
      event,
    });
    try {
      this.validateInput(event.payload);
      const output = await this.runStep(event, step);
      console.log({
        message: `${this.getName()} completed.`,
        level: "info",
        event,
        output,
      });
      return output;
    } catch (error) {
      console.log({
        message: `${this.getName()} failed.`,
        level: "error",
        event,
        error,
      });
      throw error;
    }
  }
}

`
export abstract class AbstractWorkflow<T, R> extends WorkflowEntrypoint<Env, T> {
  protected abstract getName(): string;
  protected abstract validateInput(input: T): void;
  protected abstract runStep(event: WorkflowEvent<T>, step: WorkflowStep): Promise<R>;

  async run(event: WorkflowEvent<T>, step: WorkflowStep): Promise<unknown> {
    console.log({
      message: `${this.getName()} started.`,
      level: "info",
      event,
    });
    try {
      this.validateInput(event.payload);
      const output = await this.runStep(event, step);
      console.log({
        message: `${this.getName()} completed.`,
        level: "info",
        event,
        output,
      });
      return output;
    } catch (error) {
      console.log({
        message: `${this.getName()} failed.`,
        level: "error",
        event,
        error,
      });
      throw error;
    }
  }
}

// src/workers/my.worker.ts

import { MyWorkflow } from "../workflows/my.workflow";

export {
   MyWorkflow
};


type Bindings = {
  MY_WORKFLOW: Workflow;
};

const app = new Hono<{ Bindings: Bindings }>();

app.post('/', async (c) => {
  return c.env.MY_WORKFLOW.create(..);
}) 

export default {
  fetch: app.fetch,
};

// src/workers/my.worker.ts

import { MyWorkflow } from "../workflows/my.workflow";

export {
   MyWorkflow
};


type Bindings = {
  MY_WORKFLOW: Workflow;
};

const app = new Hono<{ Bindings: Bindings }>();

app.post('/', async (c) => {
  return c.env.MY_WORKFLOW.create(..);
}) 

export default {
  fetch: app.fetch,
};

[32mdetails:[0m { "request_id": "ae65c446-f13d-4f95-98b8-ed25ccfa47e6", "fileId": "a386a543-91f9-4a78-af85-257ee4ba2728", "error": "internal error", "stack": "Error: internal error\n at callFetcher (cloudflare-internal:workflows-api:24:15)\n at async WorkflowImpl.create (cloudflare-internal:workflows-api:78:24)\n at async fileUploadService (main.js:919559:11)\n at async fileUploadController (main.js:919663:32)\n at async dispatch (main.js:1116:21)\n at async main.js:859416:9\n at async dispatch (main.js:1116:21)\n at async main.js:859416:9\n at async dispatch (main.js:1116:21)\n at async main.js:967997:5" }",

[32mdetails:[0m { "request_id": "ae65c446-f13d-4f95-98b8-ed25ccfa47e6", "fileId": "a386a543-91f9-4a78-af85-257ee4ba2728", "error": "internal error", "stack": "Error: internal error\n at callFetcher (cloudflare-internal:workflows-api:24:15)\n at async WorkflowImpl.create (cloudflare-internal:workflows-api:78:24)\n at async fileUploadService (main.js:919559:11)\n at async fileUploadController (main.js:919663:32)\n at async dispatch (main.js:1116:21)\n at async main.js:859416:9\n at async dispatch (main.js:1116:21)\n at async main.js:859416:9\n at async dispatch (main.js:1116:21)\n at async main.js:967997:5" }",

export default {
    async fetch(req: Request, env: Env): Promise<Response> {
        let instance = await env.DATA_WORKFLOW.create();
        return Response.json({
            id: instance.id,
            details: await instance.status(),
        });
    },
};

export default {
    async fetch(req: Request, env: Env): Promise<Response> {
        let instance = await env.DATA_WORKFLOW.create();
        return Response.json({
            id: instance.id,
            details: await instance.status(),
        });
    },
};

async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
        const storageKey = `instructions-${event.instanceId}.json`;
        const defaultConfig = {retries: { limit: 1, delay: 1000 }};

        try {
            const ids = await step.do('download ids', defaultConfig, async () => {
                //
            });

            await step.do('do something with ids', defaultConfig, async () => {
                //
            });

            await step.do('do something with ids', defaultConfig, async () => {
                //
            });

            // Cleanup after successful completion
            await this.env.TEMP_STORAGE.delete(storageKey);
        } catch (error) {
            // Cleanup on failure
            await this.env.TEMP_STORAGE.delete(storageKey);
            throw new NonRetryableError("Unknown error");
        }

        let workflow = await this.env.DATA_WORKFLOW.get(event.instanceId);
        await workflow.terminate();
    }

async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
        const storageKey = `instructions-${event.instanceId}.json`;
        const defaultConfig = {retries: { limit: 1, delay: 1000 }};

        try {
            const ids = await step.do('download ids', defaultConfig, async () => {
                //
            });

            await step.do('do something with ids', defaultConfig, async () => {
                //
            });

            await step.do('do something with ids', defaultConfig, async () => {
                //
            });

            // Cleanup after successful completion
            await this.env.TEMP_STORAGE.delete(storageKey);
        } catch (error) {
            // Cleanup on failure
            await this.env.TEMP_STORAGE.delete(storageKey);
            throw new NonRetryableError("Unknown error");
        }

        let workflow = await this.env.DATA_WORKFLOW.get(event.instanceId);
        await workflow.terminate();
    }

// ✅ Good: steps that are dynamically named are constructed in a deterministic way.
    // In this case, `catList` is a step output, which is stable, and `catList` is
    // traversed in a deterministic fashion (no shuffles or random accesses) so,
    // it's fine to dynamically name steps (e.g: create a step per list entry).
    let catList = await step.do("get cat list from KV", async () => {
      return await env.KV.get("cat-list");
    });

    for (const cat of catList) {
      await step.do(`get cat: ${cat}`, async () => {
        return await env.KV.get(cat);
      });
    }

// ✅ Good: steps that are dynamically named are constructed in a deterministic way.
    // In this case, `catList` is a step output, which is stable, and `catList` is
    // traversed in a deterministic fashion (no shuffles or random accesses) so,
    // it's fine to dynamically name steps (e.g: create a step per list entry).
    let catList = await step.do("get cat list from KV", async () => {
      return await env.KV.get("cat-list");
    });

    for (const cat of catList) {
      await step.do(`get cat: ${cat}`, async () => {
        return await env.KV.get(cat);
      });
    }