You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It may be nice to have a programmatic approach to designing workflows for a task. Here's an example:
# when a worker accepts a task, a stateful workflow# method gets called, which yields task dataasyncdefworkflow(state):
state.set("role", lambda: random("speaker", "listener"))
# throws if worker fails onboarding, no more tasks sent:assertawaitonboarding_task()
forxinrange(3):
forninrange(10):
awaittask(state.role)
# throws if worker fails gold task, no more tasks sent:assertawaitgold_task()
Some implementation notes
The workflow method is designed to be resumable. This means that it needs to keep track of state. It also means that "side-effects" are cached. For example, the first time a user accepts a HIT, the await suspends for onboarding_task. The next time a user accepts a HIT, the await is instantaneous for onboarding_task because the workflow fn is state-aware and caches the previous result.
Open question: do we allow users to modify the file in between runs? That could mess things up big time, and cause inconsistencies
The text was updated successfully, but these errors were encountered:
It may be nice to have a programmatic approach to designing workflows for a task. Here's an example:
Some implementation notes
The workflow method is designed to be resumable. This means that it needs to keep track of state. It also means that "side-effects" are cached. For example, the first time a user accepts a HIT, the await suspends for
onboarding_task
. The next time a user accepts a HIT, the await is instantaneous foronboarding_task
because theworkflow
fn is state-aware and caches the previous result.The text was updated successfully, but these errors were encountered: