Page MenuHomePhabricator

Expand usage of x-triggered-by
Closed, DeclinedPublic

Description

We use the x-triggered-by header in ChangeProp do break the loops between CP and RESTBase if they ever occur. The idea is that each resource_change have an x-triggered-by header and as the requests and events flow in the system, resource identifiers get appended to the header and passed forward. ChangeProp then is capable of analyzing the header and detecting loops - if one occurs it's broken and an error is logged.

However, as shown in the parent task, loops can involve more services, MCS in this particular case, so the use of the header should be expanded to all services.

Event Timeline

Pchelolo triaged this task as Medium priority.Sep 7 2018, 11:09 PM
Pchelolo created this task.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 7 2018, 11:09 PM
cscott added a subscriber: cscott.Sep 20 2018, 4:29 PM

Should Parsoid be propagating x-triggered-by from request to response?

bearND added a subscriber: bearND.Sep 20 2018, 6:09 PM

It would be good to add some acceptance criteria to this so we can derive some test cases and know exactly what e.g. MCS needs to do.

Should Parsoid be propagating x-triggered-by from request to response?

No.

It would be good to add some acceptance criteria to this so we can derive some test cases and know exactly what e.g. MCS needs to do.

Actually, after reflecting on it more, I think it's better if MCS just passes through the header unchanged.

Shouldn't we be doing x-request-id (T201409) instead?

These are different things designed for different purpose, so you should do both.

WDoranWMF closed this task as Declined.Oct 8 2019, 6:48 PM