You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello.
I've seen a recurring issue with the aggregator and the way Azure DevOps handles events : if you have a few failed requests (like because of an error in a rule or issue with the azure function), the service hook is restricted, and all following events are not sent. In the same way, when there is an issue, the event is lost, and there's no way to get it processed later.
A way to fix this reliability issue would be to have a queue in between the service hook and the actual function. Basically instead of calling a azure function, the hook would send a message to the queue that would then be dequeued by the function. In case of an error, the message is put back on the queue for later treatment. If the error is occurring a number of times, the message could be put in a dead letter queue but at least there would be more that one try, and also we wouldn't loose any messages.
This has quite deep impacts (on the CLI mostly and function bindings also), but it would definitely improves the overall reliability of the aggregator
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello.
I've seen a recurring issue with the aggregator and the way Azure DevOps handles events : if you have a few failed requests (like because of an error in a rule or issue with the azure function), the service hook is restricted, and all following events are not sent. In the same way, when there is an issue, the event is lost, and there's no way to get it processed later.
A way to fix this reliability issue would be to have a queue in between the service hook and the actual function. Basically instead of calling a azure function, the hook would send a message to the queue that would then be dequeued by the function. In case of an error, the message is put back on the queue for later treatment. If the error is occurring a number of times, the message could be put in a dead letter queue but at least there would be more that one try, and also we wouldn't loose any messages.
This has quite deep impacts (on the CLI mostly and function bindings also), but it would definitely improves the overall reliability of the aggregator
Beta Was this translation helpful? Give feedback.
All reactions