-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workflow for Zebra #163
Comments
Temporal can begin once one of the criteria is met.
Can check if a given user exists to verify
Can check the status to verify
Based on status / requests |
Preferably, both a synchronous and an asynchronous execution will be used. |
workflow --> --> No --> don't execute activity |
func Workflow(ctx workflow.Context, resource zebra.Resource, store Zebra.Store) (string, error){
} func ActivityRequested(ctx context.Context, store zebra.Store, email string) (string, error) { func ActivityLoggedIn(ctx context.Context, store zebra.Store, email string) (string, error) { |
Things to consider:
|
Worker options to consider: EnableSessionWorker DeadlockDetectionTimeout |
ActivityOptions not necessarily needed ClientOptions may be needed |
To consider making async :
To consider including in parallel exec logic:
|
Will only use for async situations |
For notification temporal, notification code is needed and may be divided into multiple parts. |
Use temporal with wrapper functions that contain the Zebra logic. |
Need a time parameter, to timeout |
Currently using StartToCloseTimeout for the time parameter |
May want to consider adding an additional verification step to distinguish between activities that get triggered, especially when an activity can be subdivided into multiple activities. |
Options for including API on top of temporal |
May consider including a lock/mutex to protect critical sections. |
There can be an interface for all temporal-related functions. |
Temporal should use abstraction |
Set up black-box style logic |
The abstraction can have an initial condition and an exit condition. |
Other things that should exist in the abstraction:
|
The initial condition can be one / many. Currently, it is more granular. |
If there is ONE initial condition, it could possibly be the log in. If there are more, each can work as independent conditions. |
Think: How will the exit condition be determined ? |
Some ideas:
|
Ideas to consider:
|
Ideas for implementing a temporal workflow for Zebra.
The text was updated successfully, but these errors were encountered: