Comment by rubenfiszel | Hacker News Reader

Comment by rubenfiszel | Hacker News Reader

Parent Full thread

1. Yes there are no time limits for workflows and there is no cost to keep a workflow suspended. It will just be scheduled to be reactivated in the future

2. The webhook can contain a payload, and you can but the suspend step into a for-loop. You could literally say, for-loop forever the suspend until the result of the suspend step (which can be the result of the evaluation of the webhook payload by your rule is true). For that, you will need to use another primitive that we expose which is "Break" that will break out of the for-loop

3. I'm a bit unsure of the term synchronous call. We have a long list of APIs https://app.windmill.dev/openapi.html#/ and you fetch the status of the flow or trigger a flow in a synchronous http webhook to wait for the result. As to force the state of the workflow. We do not expose something like that but it could be added easily.

Happy to chat if we could be a good fit for your needs: ruben@windmill.dev

Thank you! It doesn't sound like an exact fit but Windmill looks great in general, well done!

For the second point, the idea is that we don't want to rely on webhooks at all, except as evaluation triggers. The rules are built in to each state, so even if we've missed a webhook/event, the customer can still proceed.

For an example, one of our flows requires the user to have filled out a consent form in the last three months. As I understand it, with your design, we need to send a webhook when a user has given consent, and then we can proceed to the next state, so we'd have to somehow check for previous consent in some different state? With our design, when the user reaches the state, the rules will be evaluated, and "has given consent within the last three months" will be true, and the user will proceed to the next state without ever seeing the consent form.

For the synchronous bit, it kind of follows from the above feature, and it is so we evaluate state transitions while the user is waiting. We run the workflow synchronously, in the request (since no workflow needs external events to continue), and return the new state to the user.

Since this is synchronous, it avoids races or long waits for events to be delivered.

Thanks for listening, maybe you'll find some of the above helpful in your design!

Makes sense. I understand the synchronous part now. I think there are ways to achieve the same benefits with an asynchronous system but if what you have works, no point changing it!

Reply on news.ycombinator.com