GetStateKeysEntryMessage

Author: slinkydeveloper

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

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