Do not emit an event if it will cause a loop#607
Conversation
Perhaps
Yeah, I think this would be really useful. Even in the absence of loops, it's really useful to see where an event came from. |
sys/events.js
Outdated
| // the same event, it will cause a rerender loop. So, log an error and skip | ||
| // an event. | ||
| var reRenderReason = req.headers && req.headers['x-rerender-reason'] | ||
| || hyper._rootReq && hyper._rootReq['x-rerender-reason']; |
There was a problem hiding this comment.
[minor, bikeshed, alternative]: x-triggers, x-triggered-by, x-event-path, or x-events?
There was a problem hiding this comment.
x-restbase-triggered-by?
There was a problem hiding this comment.
I think we may want to make it independent of RESTBase. We don't want to re-emit an event for the same URI/topic combo regardless of the original source.
|
Updated to match the changes in https://github.com/wikimedia/change-propagation/pull/32 |
sys/events.js
Outdated
| }) | ||
| .filter(function(event) { return !!event; }); | ||
|
|
||
| // Change-propagation will set up the x-rerender-reason header, indicating |
|
Minor nits, LGTM otherwise |
|
@d00rman updated |
|
Changes Unknown when pulling acffff4 on Pchelolo:rerender_cause into * on wikimedia:master*. |
After an outage we've discovered, that when change-prop is introduced, some bugs playing together might cause rerender loops in RESTBase, when change-prop serenaders some content, and it creates the same event that caused a rerender to happen.
This PR adds some protection against it - change-prop will add the
x-rerender-reasonheader (name subject to a bike shed) to a RESTBase request, containing an original event URI (it's enough as RB only emitsresource_changeevents). If we are about to emit the same event causing a cycle - log an error and drop the event.Questions:
PS: need to add this header in change-propagation.
cc @wikimedia/services