Change Details

In case a rule processing failed, change propagation service needs to be able to retry the rule execution. In order to do it reliably, it will post a message to the static retry topic. As other consumers of an #eventbus could benefit from the ability to use retry topics, we want to set them up transparently for each topic created in kafka. A retry message will contain an original failed rule, so a consumer of a retry message would know which rule to execute. So, here's the list of things that should be done: [] Set up a schema for a retry topic. [] Make event logging-service transparently create a retry topic for each topic created and accept messages for this topic. [] Set up retry consumers in change propagation. [[ https://github.com/wikimedia/change-propagation/pull/6 | WIP PR ]]

In case a rule processing failed, change propagation service needs to be able to retry the rule execution. In order to do it reliably, it will post a message to the static retry topic. As other consumers of an #eventbus could benefit from the ability to use retry topics, we want to set them up transparently for each topic created in kafka. A retry message will contain an original failed rule, so a consumer of a retry message would know which rule to execute. So, here's the list of things that should be done: [] Set up a schema for a retry topic. [] Make event logging-service transparently create a retry topic for each topic created and accept messages for this topic. It's questionable whether we want this or not, as retry topics will be useful only for #eventbus while the producer service might be useful for other applications where retry topics are not needed. So, I think it's better just to set the topics in the `eventbus-topics.yaml` config file @mobrovac @Ottomata what do you think? [] Set up retry consumers in change propagation. [[ https://github.com/wikimedia/change-propagation/pull/6 | WIP PR ]]

In case a rule processing failed, change propagation service needs to be able to retry the rule execution. In order to do it reliably, it will post a message to the static retry topic. As other consumers of an #eventbus could benefit from the ability to use retry topics, we want to set them up transparently for each topic created in kafka. A retry message will contain an original failed rule, so a consumer of a retry message would know which rule to execute. So, here's the list of things that should be done: [] Set up a schema for a retry topic. [] Make event logging-service transparently create a retry topic for each topic created and accept messages for this topic. It's questionable whether we want this or not, as retry topics will be useful only for #eventbus while the producer service might be useful for other applications where retry topics are not needed. So, I think it's better just to set the topics in the `eventbus-topics.yaml` config file @mobrovac @Ottomata what do you think? [] Set up retry consumers in change propagation. [[ https://github.com/wikimedia/change-propagation/pull/6 | WIP PR ]]