eersnington

Context

• Optimize for: correct, performance, and maintainable changes
• Do not use submit_plan() unless the user asks to "submit a plan"
• Compose plans in mainly in call graphs and code that are easy to understand and follow
• Never create commits, PRs, or push unless explicitly requested and ask what should the commit message be
• Never add AI/Agent attribution or contributor status in commits,
• ALWAYS check for .jj/ before ANY VCS command; if present, prefer jj
• In colocated repos, use jj for normal workflow unless the task specifically requires git
• gh CLI available for GitHub operations (PRs, issues, etc.)

eersnington

This is a more structured draft on a way to cancel Workflow steps that I would like to see after I made an attempt at improving parallel execution of steps within Cloudflare Workflows with cf-forklift.

Some details may need a refresh and more thinking, but I wanted to post this to get thoughts and see if/where it breaks in the real world. Please do comment on how well/poorly this would work for different usecases as I think this can be iterated on and be shipped as a first class runtime API

I came across @wishee0's tweet about wanting feedback for cloudflare workflows, and saw that @ksw_arman from @thecontextco mentioned that wrapping parallel steps in promise.all() and promise.allSettled() isn't a great experience.

I've looked through the docs, fiddled around with the API and shipped a workflow app. And I do think that there's an opportunity here to improve this drastically.

// A deceptively simple example of parallel workflow step execution

eersnington

RFC For Deterministic pollUntil() function

Allow me a moment for my pessimistic side to take control of this gist to say that this RFC might be more of a Reasonably Futile Concept rather than being a Request For Comments. But I've been looking into the what, hows, and whys of this amalgamation of thinking tokens for quite a while with the current mental model of WDK, and maybe what can be done about it.

Ground Zero

Polling isn't ideal (side-note: I think WDK has the potential to cheat it), but I keep seeing this pattern of WDK code (and even my best friend when I showed WDK primitives) which made me go down this rabbit hole. I wrote this gist to spell out why is "call status -> sleep -> repeat" loop feels natural, how it actually plays with determinism, and what a first-class helper could do to make it easier for everyone.

1. The useReflex: I'll just loop and slap in an await sleep("15s")