Remove legacy messages

[danielmarbach]

No description provided.

[danielmarbach]

@Particular/servicecontrol-maintainers given that we are now at version 2.0 and working on essentially the next major version is it safe to remove this code?

[mikeminutillo]

I think in almost all cases this should be fine BUT there's never a 100% perfectly safe way to remove these. We don;t know the version that we are upgrading from and we don't technically know what messages might be on the wire. This is part of the reason that SC shouldn't talk to itself via the transport.

[SzymonPobiega]

Can we first move them to a separate legacy.cs file and make them (the handlers) log warn instead of doing actual work?

[danielmarbach]

@SzymonPobiega what would be the benefit of that and how would we get that information back once that log warn occurs at a customer site?

[SzymonPobiega]

@danielmarbach we would not get that information back :-( What I meant is that

• It is OK to simplify the code to a degree that processing these messages is NOOP
• It is not OK to simplify the code if the simplified code crashes when such a message is handled

[danielmarbach]

I did some digging. We introduced this as part of 1.39 which was release 3rd April 2017. The latest 1.x release is 1.48. The major upgrade that we released was 2.0.2 and now we are essentially working on 3.0. I think it is reasonable to assume that people who installed 1.39 can catch up with the 1.x range and gradually migrate to the next major. We can even document that on the docs site. I'm for removing it but I have not enough context to make the decision. @Particular/servicecontrol-maintainers thoughts?

// cc @janovesk @WojcikMike you guys have been involved in the efforts around 1.39 maybe you can chime in as well.

[SzymonPobiega]

@danielmarbach how about a behavior early in the pipline that discard messages based on the type? Then we can have a hard-coded list of message types that we no longer support. It would be a single behavior with a single list.

[danielmarbach]

That comes at the cost of parsing the enclosed message type header for every message that comes into service control as well as potentially removing the assembly qualified part from the string to do a match against

            "ServiceControl.MessageFailures.InternalMessages.PerformRetry",
            "ServiceControl.MessageFailures.InternalMessages.RegisterSuccessfulRetry"

is that worth it?

[SzymonPobiega]

@danielmarbach can we just used the String.StartsWith() and pass the type name followed by a comma?

[WilliamBZA]

Closing this as it is probably better to be re-implemented rather than trying to rebase. Probably also worth re-discussing the points above too.