We've got a million Webhook classes and a million Manager classes. This tries to name some of them more aptly.
WebhookManager is the class that's responsible for making sure that all active webhooks are running on one and only one node. Coordinator seemed slightly more appropriate, even if it's also an overused name.
LocalWebhookManager is where webhooks are actually running, updating state, delivering items, etc. It's who we ask if we want to know what webhooks a particular node is actually leading. I dropped Manager for the still bad, but slightly more specific Runner.
WebhookContentPathSet aka groupSet aka groupInFlight is now WebhookContentInFlight and it's ZK state of all the content keys that are currently trying to be delivered to webhook callbacks.
I'm open to better names. These made it easier for me to reason about flow for the data loss bug...
We've got a million
Webhookclasses and a millionManagerclasses. This tries to name some of them more aptly.WebhookManageris the class that's responsible for making sure that all active webhooks are running on one and only one node.Coordinatorseemed slightly more appropriate, even if it's also an overused name.LocalWebhookManageris where webhooks are actually running, updating state, delivering items, etc. It's who we ask if we want to know what webhooks a particular node is actually leading. I droppedManagerfor the still bad, but slightly more specificRunner.WebhookContentPathSetaka groupSet aka groupInFlight is nowWebhookContentInFlightand it's ZK state of all the content keys that are currently trying to be delivered to webhook callbacks.I'm open to better names. These made it easier for me to reason about flow for the data loss bug...