Maniphest T203854

Expand usage of x-triggered-by
Closed, DeclinedPublic
Actions

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.

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Resolved		• Pchelolo	T194190 Infinite rerender loop in RESTBase
		Declined		• Pchelolo	T203854 Expand usage of x-triggered-by

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

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

• Mholloway moved this task from Needs triage to Backlog on the Product-Infrastructure-Team-Backlog-Deprecated board.Sep 20 2018, 4:36 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.

• Mholloway moved this task from Backlog to Needs investigation on the Product-Infrastructure-Team-Backlog-Deprecated board.Sep 21 2018, 5:27 AM

In T203854#4602628, @cscott wrote:

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

No.

In T203854#4603144, @bearND wrote:

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?