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
Rather than using the combination service name + service key + invocation id + entry index, we could use simply partition key + invocation id + entry index. This would make the awakeable id bounded, solving problems such as restatedev/proto#21 (comment) and it would not leak the service key anymore.
The content you are editing has changed. Please copy your edits and refresh the page.
Rather than using the combination service name + service key + invocation id + entry index, we could use simply partition key + invocation id + entry index. This would make the awakeable id bounded, solving problems such as restatedev/proto#21 (comment) and it would not leak the service key anymore.
Tasks
ServiceInvocationId
fromPartitionKey
andInvocationId
. This operation would effectively scan the status table usingPartitionKey
as prefix, deserialize the Status, and stop on the first match ofInvocationId
#706InvocationResponse
data structure to support bothServiceInvocationId
and a newtype (name TBD) that contains onlyPartitionKey
andInvocationId
to address the caller invocation. In case the newtype is found, the state machine needs to use the aforementioned scan operation to retrieve theServiceInvocationId
#707AwakeableIdentifier
(perhaps getting rid of theAwakeableIdentifier
message?), carry thepartition_key
inStartMessage
and modify theCompleteAwakeableEntryMessage
accordingly service-protocol#46AwakeableIdentifier
format sdk-typescript#154AwakeableIdentifier
format sdk-java#107The text was updated successfully, but these errors were encountered: