This PR improves topology validation and allows for new kinds of topologies:
We now catch and report to the user when two protocol incompatible transforms are connected to each other. Previously this would just blow up at runtime with a confusing error.
We now allow topologies like: CassandraToRedisTransform -> Tee
Previously this would have failed since Tee relies on the protocol type being correctly set in TransformContextConfig but the protocol was only set to the protocol of the source and any changes to the protocol via previous transforms was ignored.
Not sure if up chain and down chain are the clearest way to name these but I also cant think of anything better.
I considered incoming and outgoing but I feel that is confusing since that its not clear what perspective its coming from.
Incoming could mean coming from the client but that would only be correct from the perspective of requests, since responses are actually outgoing to the client.
Work to do in follow up PRs:
Correctly declare protocols for all existing transforms and make up_chain_protocol and down_chain_protocol mandatory
Improve diagnostic formatting, when compared to the existing diagnostics for TransformBuilder::validate and TransformBuilder::is_terminate the diagnostics formatting is not as good. We will need to build up similar abstractions for diagnostics on config as we have for builders.
Remove TransformBuilder::is_terminating, its redundant now since DownChainProtocol is a superset of that information.
Progress towards https://github.com/shotover/shotover-proxy/issues/520
This PR improves topology validation and allows for new kinds of topologies:
CassandraToRedisTransform
->Tee
TransformContextConfig
but the protocol was only set to the protocol of the source and any changes to the protocol via previous transforms was ignored.Not sure if up chain and down chain are the clearest way to name these but I also cant think of anything better. I considered incoming and outgoing but I feel that is confusing since that its not clear what perspective its coming from. Incoming could mean coming from the client but that would only be correct from the perspective of requests, since responses are actually outgoing to the client.
Work to do in follow up PRs:
up_chain_protocol
anddown_chain_protocol
mandatoryTransformBuilder::validate
andTransformBuilder::is_terminate
the diagnostics formatting is not as good. We will need to build up similar abstractions for diagnostics on config as we have for builders.TransformBuilder::is_terminating
, its redundant now sinceDownChainProtocol
is a superset of that information.