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
(select service_key from state where key = 'snapshot' and json_get_str(value_utf8, 'status') != 'done')
89
89
select state.service_key, state.value_utf8 from keys right join state where keys.service_key = state.service_key and key = 'version'"
90
90
```
91
+
92
+
## Subscribing to changes
93
+
94
+
Calls to `create` or `send` always return immediately with the results of any synchronous transitions that were triggered.
95
+
The state machine may later transition due to delayed transitions or promise actors.
96
+
It is helpful to be able to subscribe to the state machine to wait for relevant changes.
97
+
In native xstate this would be done with the `subscribe` method and the `waitFor` function.
98
+
In the Restate integration we expose a similar mechanism via the `waitFor` handler.
99
+
100
+
`waitFor` accepts two parameters, `condition`, which describes what you're waiting for, and an optional `timeout` parameter which is how many milliseconds to wait before returning an error (HTTP 408) to the caller.
101
+
The `condition` parameter currently accepts either `done`, which is met if the state machine enters a state with `type: "final"`, or `hasTag:${tag}`, which is met if the state machine enters a state with that tag.
102
+
When the condition is met, the waitFor request returns with the snapshot of the state machine that met the condition.
103
+
If the state machine completes or enters an error state without the condition being met, `waitFor` returns an error (HTTP 412).
104
+
105
+
To safely watch for a change from HTTP clients, its best to use idempotent invocations.
106
+
These allow for interrupted HTTP requests to `waitFor` to be resumed by simply making the request again with the same idempotency key, without having to initiate a new `waitFor` invocation (in which case, you might miss a state change in the gap between the two requests).
107
+
This means that even if your wait time exceeds HTTP response timeouts, you can safely keep long-polling for completion.
108
+
109
+
For example:
110
+
111
+
```bash
112
+
# start a local Restate instance
113
+
restate-server
114
+
# start the service
115
+
npm run examples
116
+
# register the state machine service against restate
117
+
restate dep register http://localhost:9080
118
+
119
+
# create a state machine
120
+
curl http://localhost:8080/auth/myMachine/create
121
+
# create a waitFor invocation which waits for the machine to complete
0 commit comments