From 038b5335d571d865b0a958c6eefcca179486e987 Mon Sep 17 00:00:00 2001 From: slinkydeveloper Date: Wed, 7 Feb 2024 15:53:24 +0100 Subject: [PATCH] `GetStateKeysEntryMessage` --- dev/restate/service/protocol.proto | 14 ++++++++++++++ service-invocation-protocol.md | 14 ++++++++------ 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/dev/restate/service/protocol.proto b/dev/restate/service/protocol.proto index 410632a..32b0f91 100644 --- a/dev/restate/service/protocol.proto +++ b/dev/restate/service/protocol.proto @@ -151,6 +151,20 @@ message ClearStateEntryMessage { bytes key = 1; } +// Completable: Yes +// Fallible: No +// Type: 0x0800 + 4 +message GetStateKeysEntryMessage { + message StateKeys { + repeated bytes keys = 1; + } + + oneof result { + StateKeys value = 14; + Failure failure = 15; + }; +} + // ------ Syscalls ------ // Completable: Yes diff --git a/service-invocation-protocol.md b/service-invocation-protocol.md index 657a02c..d8fffb6 100644 --- a/service-invocation-protocol.md +++ b/service-invocation-protocol.md @@ -90,8 +90,8 @@ Each syscall defines a priori whether it replies with an ack or a completion, or ## Messages -The protocol is composed by messages that are sent back and forth between runtime and the service deployment. The protocol -mandates the following messages: +The protocol is composed by messages that are sent back and forth between runtime and the service deployment. The +protocol mandates the following messages: - `StartMessage` - `[..]EntryMessage` @@ -284,6 +284,7 @@ descriptions in [`protocol.proto`](dev/restate/service/protocol.proto). | ------------------------------- | -------- | ----------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `PollInputStreamEntryMessage` | `0x0400` | Yes | No | Carries the invocation input message(s) of the invocation. Note: currently the runtime always sends this entry completed, but this may change in future. | | `GetStateEntryMessage` | `0x0800` | Yes | No | Get the value of a service instance state key. | +| `GetStateKeysEntryMessage` | `0x0804` | Yes | No | Get all the known state keys for this service instance. Note: the completion value for this message is a protobuf of type `GetStateKeysEntryMessage.StateKeys`. | | `SleepEntryMessage` | `0x0C00` | Yes | No | Initiate a timer that completes after the given time. | | `InvokeEntryMessage` | `0x0C01` | Yes | Yes | Invoke another Restate service. | | `AwakeableEntryMessage` | `0x0C03` | Yes | No | Arbitrary result container which can be completed from another service, given a specific id. See [Awakeable identifier](#awakeable-identifier) for more details. | @@ -298,8 +299,9 @@ descriptions in [`protocol.proto`](dev/restate/service/protocol.proto). When creating an `AwakeableEntryMessage`, the SDK MUST expose to the user code an id, required to later complete the entry, using either `CompleteAwakeableEntryMessage` or some other mechanism provided by the runtime. -The id format is a string starts with `prom_1` concatenated with a [Base64 URL Safe string](https://datatracker.ietf.org/doc/html/rfc4648#section-5) encoding of a byte -array that concatenates: +The id format is a string starts with `prom_1` concatenated with a +[Base64 URL Safe string](https://datatracker.ietf.org/doc/html/rfc4648#section-5) encoding of a byte array that +concatenates: - `StartMessage.id` - The index of the Awakeable entry, encoded as unsigned 32 bit integer big endian. @@ -331,8 +333,8 @@ To notify a failure, the SDK can either: - Close the stream with `ErrorMessage` as last message. This message is used by the runtime for accurate reporting to the user. -- Close the stream without `EndMessage` or `SuspensionMessage` or `ErrorMessage`. This is equivalent to sending - an `ErrorMessage` with unknown reason. +- Close the stream without `EndMessage` or `SuspensionMessage` or `ErrorMessage`. This is equivalent to sending an + `ErrorMessage` with unknown reason. The runtime takes care of retrying to execute the invocation after such failures occur, following a defined set of policies. When retrying, the previous stored journal will be reused. Moreover, the SDK MUST NOT assume that every