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.
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.
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.
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.
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.
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: |
| "log" | ||
|
|
||
| queries "interacting/exercises/querying-workflows/solution" | ||
| queries "interacting/exercises/querying-workflows/practice" |
There was a problem hiding this comment.
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, |
| 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.
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.
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 |
2 participants
Some things noted by fresh eyes
One is important -- the some import statements in the practice code were importing from the solution