-
Notifications
You must be signed in to change notification settings - Fork 2
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
Grant-onboarding #12
base: main
Are you sure you want to change the base?
Grant-onboarding #12
Conversation
1. Edit the `workflow.go` file. You will use the `workflow.SetQueryHandler()` to add Query handling to your Workflow. This can be done anywhere inside of the `Workflow()` function. In this case, you'll add a query to return the Workflow's `currentState`, so it makes sense to initialize the `currentState` variable as you go along. Note that this is the same Workflow from the previous exercise, so it is designed to wait for a Signal after starting. | ||
1. Edit the `workflow.go` file. | ||
|
||
You will use the `workflow.SetQueryHandler()` to add Query handling to your Workflow. This can be done anywhere inside of the `Workflow()` function. In this case, you'll add a query to return the Workflow's `currentState`, which you'll modify as the Workflow progresses. Note that this is the same Workflow from the previous exercise, so it is designed to wait for a Signal after starting. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tom suggested to me one time to separate prose from instruction/commands. I tried to do that here -- totally up to you on whether or not to keep it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just adding a linebreak is a pretty reasonable way of doing that imo! I'd previously rejected suggestions along these lines that distorted the number of actual steps there were, but this works fine. Thanks!
4. Finally, update `currentState` again after that block of code, to something like "waiting for signal". This is the state that the Workflow will be waiting at when we query it. | ||
5. Save the file. | ||
4. Update `currentState` again after that block of code, to something like "waiting for signal". This is the state that the Workflow will be waiting at when we query it. | ||
5. Finally, update `currentState` to something like `"Workflow Complete"` | ||
after the Activity has completed successfully near where the Workflow completion is logged. | ||
6. Save the file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this note to change to add a statement for workflow complete. It used to be in part E, but I just moved it here. I think it's easier to have it here because I think if it's in E, the user needs to restart workers etc
response, err := c.QueryWorkflow(context.Background(), "queries", "", "current_state") | ||
response, err := c.QueryWorkflow(context.Background(), "queries-workflow-id", "", "current_state") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not necessary, but it had the workflow id and the task queue both as "queries", so I just changed them to disambiguate
Now you can send a Signal to your Workflow as in the previous exercise so it completes successfully. In the terminal you sent your Query from, run `go run signalclient/main.go`. | ||
Now you can send a Signal to your Workflow as in the previous exercise so it completes successfully. | ||
|
||
1. In the terminal you sent your Query from, run `go run signalclient/main.go`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
separating prose from instructions. up to you 👍
|
||
## Part E: Querying a Completed Workflow | ||
|
||
Finally, you can demonstrate querying completed Workflows. Update the `currentState` variable in `workflow.go` once more just before the Workflow returns, so that you can demonstrate querying a completed workflow. Then, re-run the workflow, and query it from the command line again: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved to part A
queries "interacting/exercises/querying-workflows/solution" | ||
queries "interacting/exercises/querying-workflows/practice" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
significant change -- the practice code was importing from the solution, so the user's code would be working even if they didn't solve the problem yet. Lol I had this happen to me and i was pretty confused
1. This exercise contains one Client that runs two different Workflows | ||
— `PizzaWorkflow` and `FulfillOrderWorkflow`. Both Workflows are defined in | ||
`workflow.go`. `PizzaWorkflow` is designed not to complete its final activity | ||
— `SendBill` — until it receives a Signal from `FulfillOrderWorkflow`. You'll | ||
start by defining that Signal. Edit `workflow.go`. Near the top of the file, | ||
This exercise contains one Client that runs two different Workflows | ||
— `PizzaWorkflow` and `FulfillOrderWorkflow`. Both Workflows are defined in | ||
`workflow.go`. `PizzaWorkflow` is designed not to complete its final activity | ||
— `SendBill` — until it receives a Signal from `FulfillOrderWorkflow`. You'll | ||
start by defining that Signal. | ||
|
||
1. Edit `workflow.go`. Near the top of the file, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
prose from instruction
Signal,`fulfill-order-signal`. For `SignalExternalWorkflow` calls to block | ||
and return properly in Go, you also need to append `.Get(ctx, | ||
[return-value-pointer])` to a `SignalExternalWorkflow` call, though | ||
`[return-value-pointer]` can be `nil` here. | ||
@@@@@ the course content doesn't say anything about this `.Get`. @@@@ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, is this just about appending .Get()
to a call so it actually blocks and returns? That's definitely worth clarifying in the course content if so.
// TODO Part A: create a `var` named `signal` that is an instance of | ||
// `FulfillOrderSignal` with `Fulfilled: true`. This is the Signal that | ||
// `FulfillOrderWorkflow` will send to `PizzaWorkflow`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we were using the signal
variable as both the sending variable and the receiving variable, which I felt a little confused by. So I just made two variables -- a sent one and a received one -- both of which are in just function scopes instead of at the top
Thank you, I love everything about Go except the way it handles local imports, which is insane to me |
And @GSmithApps don't forget to mark this as Ready for Review so I can merge your suggestions directly |
Thanks so much for looking!! I have one change above ☝️ that isn't ready -- if you get a second to look, that would be awesome |
Some things noted by fresh eyes
One is important -- the some import statements in the practice code were importing from the solution