Daniel
Daniel
@dave08 The reason this is happening is that bitbucket eventsource (as well as the rest of the git related eventsources) has an “auto recovery” daemon for webhooks that is running...
@whynowy I think I have a solution for our race condition issue with `deleteHookOnFinish` which would help us get rid of the webhooks daemon mitigation once and for all, but...
> > @whynowy I think I have a solution for our race condition issue with `deleteHookOnFinish` which would help us get rid of the webhooks daemon mitigation once and for...
Fixes: #2086
> While I understand and acknowledge what I did wrong, I think the controller should handle the null and throw and error rather than hard crashing. @zamedic yes, that makes...
@whynowy @VaibhavPage do you see any complications or risks in changing that behavior?
> Maybe we can address this when we retire NATS Streaming (with Jet Stream?). Yes, makes sense 👍 BTW, regarding the subscription limit per channel that you've mentioned - isn't...
> > > Maybe we can address this when we retire NATS Streaming (with Jet Stream?). > > > > > > Yes, makes sense 👍 > > BTW, regarding...
> > The main reason that we are facing a race condition when deleteHookOnFinish is enabled is that the new eventsource pod is trying to use the same hook that...
> Regarding the solution you're proposing: If a new EventSource Pod is starting, it has no idea what `id` the previous Webhook had. Are you proposing to find the Webhook...