It would be great to have a way, in the action implementation to check if the message received comes from the local instance or from a remote instance through a transport.
Currently a transport$ attribute is added on the message when it travels through a transport, but it isn't cleared in case the message is directly forwarded to another action (example: https://github.com/senecajs/ramanujan/blob/master/timeline/timeline-shard-service.js#L17)
I think a better approach would be to add a flag to the message meta$ (meta$ should be cleared and rebuilt on each action).
As an example, here's my use-case:
I've implemented seneca-zipkin-tracer and in order to properly fully trace each action call I need to send info to the zipkin server both on the "client" instance and the "server" instance (This way more detailed info can be tracked, such as network time and clock skews).
To do this I've hooked into the seneca actions using the new inward/outward mechanism that basically allow me to run code when an action is going to be executed.
In the case of "remote" actions we will actually see the same pattern handled twice, the first time on the "client" (the implementation is provided by the transport in order to forward it to the server) and the second time on the "server" (with the actual implementation).
In this scenario I'd need a standard and safe way to check if I'm acting as the client or as the server (hence the suggestion to mark a message coming from the remote)
It would be great to have a way, in the action implementation to check if the message received comes from the local instance or from a remote instance through a transport.
Currently a
transport$
attribute is added on the message when it travels through a transport, but it isn't cleared in case the message is directly forwarded to another action (example: https://github.com/senecajs/ramanujan/blob/master/timeline/timeline-shard-service.js#L17) I think a better approach would be to add a flag to the messagemeta$
(meta$ should be cleared and rebuilt on each action).As an example, here's my use-case: I've implemented seneca-zipkin-tracer and in order to properly fully trace each action call I need to send info to the zipkin server both on the "client" instance and the "server" instance (This way more detailed info can be tracked, such as network time and clock skews). To do this I've hooked into the seneca actions using the new inward/outward mechanism that basically allow me to run code when an action is going to be executed. In the case of "remote" actions we will actually see the same pattern handled twice, the first time on the "client" (the implementation is provided by the transport in order to forward it to the server) and the second time on the "server" (with the actual implementation). In this scenario I'd need a standard and safe way to check if I'm acting as the client or as the server (hence the suggestion to mark a message coming from the remote)
In the meanwhile, I've currently resorted to this hack: https://github.com/paolochiodi/seneca-zipkin-tracer/blob/feature/update-zipkin-simple/zipkin-tracer.js#L69
Posting here on suggestion from @rjrodger to kickstart a discussion cc @mcdonnelldean @mihaidma