I'm working on the action entity support for Go. There are two aspects of the protocol and implementation that stand out in comparison to the other entity types I think. One minor difference is the naming of the Action service:

service ActionProtocol {}
service Crdt {}
service ValueEntity {}
service EventSourced {}

This is a minor thing, but I don't yet see why it has to be suffixed with Protocol.

Second, by reading the TCK and Action implementation, from a user API standpoint, the Action implementation doesn't use a context to emit side effects and choosing forwards or users service reply/responses. Differently to other entities, a io.cloudstate.javasupport.action.ActionReply is used to collect effects and choose a reply type (MessageReply, ForwardReply, FailureReply).

While the API is oriented towards the language implementing the action protocol and to be idiomatic, I'm curious if we tend or like to change the use of context objects in cloudstate APIs or like to use vehicles like the ActionReply to carry a protocols semantics. I assume we like to have where possible similar API experience for users. WDYT?