Support handlers that can read locked service instance state #1092
Assignees
Comments
slinkydeveloper
added
service-endpoint-syscall
and removed
api-devex
slinkydeveloper
added a commit
to slinkydeveloper/restate
that referenced
this issue
Mar 21, 2024
…8d559..61ae44b2 61ae44b2 Update documentation on error codes (restatedev#77) 576a1b26 Add HandlerType. Fix restatedev#1092 (restatedev#76) 0624d092 Payload schema for input and output. This provides basic format awareness. (restatedev#74) git-subtree-dir: crates/service-protocol/service-protocol git-subtree-split: 61ae44b2175c2a54c2d7a138a3368df17f389ebb
slinkydeveloper
added a commit
to slinkydeveloper/restate
that referenced
this issue
Mar 26, 2024
…8d559..29b28f98 29b28f98 Modify Input/Output schema in deployment_manifest_schema.json (restatedev#80) 26d91e69 Replace protocol Empty message with custom one, so we remove the dependency on protobuf built-in messages (restatedev#79) 61ae44b2 Update documentation on error codes (restatedev#77) 576a1b26 Add HandlerType. Fix restatedev#1092 (restatedev#76) 0624d092 Payload schema for input and output. This provides basic format awareness. (restatedev#74) git-subtree-dir: crates/service-protocol/service-protocol git-subtree-split: 29b28f9867734bc01dd47c4666d9d56c90b626f5
slinkydeveloper
added a commit
to slinkydeveloper/restate
that referenced
this issue
Mar 26, 2024
…8d559..29b28f98 29b28f98 Modify Input/Output schema in deployment_manifest_schema.json (restatedev#80) 26d91e69 Replace protocol Empty message with custom one, so we remove the dependency on protobuf built-in messages (restatedev#79) 61ae44b2 Update documentation on error codes (restatedev#77) 576a1b26 Add HandlerType. Fix restatedev#1092 (restatedev#76) 0624d092 Payload schema for input and output. This provides basic format awareness. (restatedev#74) git-subtree-dir: crates/service-protocol/service-protocol git-subtree-split: 29b28f9867734bc01dd47c4666d9d56c90b626f5
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For long running workflows it would be great if we could query its state while the workflow is running. Currently, this is not possible because the long running workflow holds the lock and no other call to the same service instance can be executed. A current workaround is to have a read-only service twin that is being updated by the workflow whenever a state change happens. This read-only service twin can then be queried by the user to read the state. Ideally, this extra service wouldn't be needed.
One idea is to allow services to have read-only methods/handlers that can read from a snapshot of the current state. With these methods, users could read service state while a long running workflow is executing.
The text was updated successfully, but these errors were encountered: