Page MenuHomePhabricator

Detect fragment destination when making a request via OrchestratorRequest
Open, In Progress, Needs TriagePublic

Description

Description

OrchestratorRequest must be able to distinguish whether a request is destined for an AW fragment or an embedded fragment (vs. to a test or a wikifunctions requested call), as a prerequisite for applying different caching strategies per request type.

Desired behavior/Acceptance criteria

  • OrchestratorRequest exposes a way to identify the fragment destination (AW vs. embedded)
  • Only calls coming from AbstractWikiRequest can be recognized as such at the OrchestratorRequest side (e.g. this cannot be faked via other interfaces)
  • Only calls coming from WikifunctionsClientRequestJob can be recognized as such at the OrchestratorRequest side (e.g. this cannot be faked via other interfaces)

Completion checklist

Event Timeline

In chatting about this, I said that locking down the API so that it can't be called from outside the cluster is very hard to achieve and it's easiest to just make it intentional, not impossible.

Change #1321621 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] Set origin header on wikilambda_function_call and propagate to OrchestratorRequest

https://gerrit.wikimedia.org/r/1321621

Change #1321621 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Set origin header on wikilambda_function_call and propagate to OrchestratorRequest

https://gerrit.wikimedia.org/r/1321621