Actors: bi-directional streaming #72
Conversation
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
20250115-actors-bi-di-stream.md
Outdated
| Each outbound `RequestRequest` message includes a `uid` field, which is a simple incrementing `uint64`. | ||
| This field must start at `1` and increment by `1` for each new request. | ||
| If a message is received from Daprd with a `uid` that is not `+1` of the previous message, the stream will be terminated. |
There was a problem hiding this comment.
Is this from Daprd or from the client?
There was a problem hiding this comment.
From the client to daprd. Sorry, that's poorly worded.
There was a problem hiding this comment.
Ah ok, that makes sense then. Thanks for clarifying 🙏
Signed-off-by: joshvanl <[email protected]>
|
|
||
| ```proto | ||
| message Request { | ||
| oneof actor_request_type { |
There was a problem hiding this comment.
There should be an error channel exposed here somewhere so that if the client requests the creation of an actor and some prerequisite on the runtime isn't met (e.g. cannot connect to the specified actor state store), such a message can be sent back to the SDK so an exception can be raised.
There was a problem hiding this comment.
Sending the error response on initialization should be covered in the ResponseInitial message sent back to the client.
There was a problem hiding this comment.
What if an error is encountered later on after initialization?
There was a problem hiding this comment.
This will be covered by the ResponeResponse message. I'm not sure whether the error should be a generic error which lives outside the oneofs, or needs to be specific to each oneof API type. I'm assuming it needs to be inside each oneof message so that it can be fully typed.
There was a problem hiding this comment.
Especially as this channel is potentially open for a little while, it'd be better to have a oneof in place so the SDK can understand if the error is transient and something that just needs the channel re-opened for or if it's more of a fatal error (and should just be logged and given up on).
I'll have to find the issue, but it's a complaint on one of the recent building blocks that when there's a failure, the SDK doesn't handle it really well because there's no real information from the runtime what to do about it except that something went wrong. It'd be great to correct that scenario here.
No description provided.