Cloudflare Developers•2w ago

Hey @avenceslau | Workflows something

Hey @avenceslau something odd happened with this workflow with the SLEEP step functionality. 1- most obvious error artificat is that there appears to be 5 "wait" steps still "RUNNING" for this workflow instance 2- this workflow was supposed to run over 7 days (with 1 day wait in between each). Yet it seems to have accelerated and run in 1 day. I double checked and we are awaiting the step.sleep and we did not touch the sleep step name. Any idea on what happened here? (link to workflow instance: https://dash.cloudflare.com/470d4729e23e8936fd2a8f6569770873/workers/workflows/trigger-workflow/instance/f70d8594-01c1-4a4c-8722-e6ace1ea29af)

14 Replies

avenceslau•2w ago

Let's do it in thread sorry @ajay | dreamlit.ai can you share the step.sleep code?

ajay | dreamlit.aiOP•2w ago

    await step.sleep(
      `wait ${waitStepConfig.staticWaitDuration} ${waitStepConfig.staticWaitDurationType}(s) (${waitTimeMs}ms)`,
      waitTimeMs,
    );

    await step.sleep(
      `wait ${waitStepConfig.staticWaitDuration} ${waitStepConfig.staticWaitDurationType}(s) (${waitTimeMs}ms)`,
      waitTimeMs,
    );

Btw this code has worked fine for many months And we haven't touched it. One thing we did do is wrap the step.sleep in a step.do Recently

avenceslau•2w ago

Oh that might be it

ajay | dreamlit.aiOP•2w ago

Maybe that had some side effect?

avenceslau•2w ago

yup I would say (off the top of my head) that there might be some strange behavior

ajay | dreamlit.aiOP•2w ago

Huh... okay. So we had some workflow instances running that were in a step.wait Then we pushed some changes that wrapped that step.wait in a step.do When those workflow instances woke up, that's what likely caused this behavior?

avenceslau•2w ago

Yup, that's it

ajay | dreamlit.aiOP•2w ago

I see.. any explanation as to why? So we can be more careful next time

ajay | dreamlit.aiOP•2w ago

(same workflow instance)

avenceslau•2w ago

The quick tldr is when you deploy a new version all instances (running or otherwise) change to the newest version of the code. When they woke up your nested step.sleep caused some weirdness inside step.do. I would avoid nesting steps, tomorrow (its a bit late for me today) I will see if there is something we can do to change that behavior (if not we will update the docs to discourage the usage of nested steps) I will get back to you in the morning Btw changelog yet to land but after you update the code you can restart that instance via wrangler (on the latest version), api, or binding.

ajay | dreamlit.aiOP•2w ago

I see, okay thank you. So the issue is only when updating existing workflow instances to the latest code - otherwise, it step.sleep inside step.do appears to work fine

avenceslau•2w ago

No, step.sleep inside of step.do might lead to undefined behavior, I would discourage that. I would advise against any step nesting tbh I will check in the morning how true this is (my brain is bit mushy at this time), but for now I would recommend against step nesting

ajay | dreamlit.aiOP•2w ago

Alright noted! We will refactor such that we return a waitUntilTimestamp from the step.do, then execute a step.wait after the step.do It's just a little tricky given we have ongoing workflow instances

Gaming

Programming

Hey @avenceslau | Workflows something

Did you find this page helpful?