[go: up one dir, main page]

Page MenuHomePhabricator

Requests to be-x-old.wikipedia.org result in HTTP 504 Gateway Timeout
Closed, ResolvedPublic

Description

While working on T304549: Deploy "add a link" to 5th round of wikis, I noticed that queries to be-x-old.wikipedia.org result in HTTP 504 Gateway timeouts.

On a deploy server, try:

curl -vvv "http://localhost:6029/v1/linkrecommendations/wikipedia/be_x_old/Foo"

The practical impact is that attempts to use https://api.wikimedia.org/service/linkrecommendation/apidocs/ with a GET request for be_x_old will fail.

The relevant application code is in MediaWikiApi.py, e.g. https://gerrit.wikimedia.org/r/plugins/gitiles/research/mwaddlink/+/refs/heads/main/src/MediaWikiApi.py#68

Acceptance criteria

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

The redirect happens correctly; from the network namespace of the main app:

kubernetes1008:~# nsenter -t 61704 -n curl -H 'Host: be-x-old.wikipedia.org' localhost:6500/ -v 2>&1 | grep location:
< location: https://be-tarask.wikipedia.org/

but then if the application doesn't funnel the request to be-tarask.wikipedia.org back via the proxy...

kubernetes1008:~# nsenter -t 61704 -n curl https://be-tarask.wikipedia.org/
curl: (28) Failed to connect to be-tarask.wikipedia.org port 443: Connection timed out

because we have no egress rule allowing to access the wikis from the public. So I think this is what you're seeing here.

Change 843954 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[research/mwaddlink@main] app: Follow redirects when we get one from the proxy

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

Some code that would work:

resp = requests.get(url, headers=headers, allow_redirects=False)
while resp.is_redirect:
   url = urlparse(resp.headers['location'])
   headers = {'Host': url.netloc}
   resp= requests.get(url._replace(netloc='localhost:6500', scheme='http').geturl(), headers=headers, allow_redirects=False)

Change 843954 abandoned by Kosta Harlan:

[research/mwaddlink@main] app: Follow redirects when we get one from the proxy

Reason:

going to use a different approach

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

Change 843968 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[research/mwaddlink@main] MediaWikiApi: Follow redirects manually

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

Change 844430 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[research/mwaddlink@main] swagger: Add an example for verifying redirection

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

Change 843968 merged by jenkins-bot:

[research/mwaddlink@main] MediaWikiApi: Follow redirects manually

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

Change 844439 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/deployment-charts@master] linkrecommendation: Bump version

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

Change 844430 merged by jenkins-bot:

[research/mwaddlink@main] swagger: Add an example for verifying redirection

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

Change 844444 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/deployment-charts@master] linkrecommendation: Bump version

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

Change 844439 merged by jenkins-bot:

[operations/deployment-charts@master] linkrecommendation: Bump version

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

Change 844444 merged by jenkins-bot:

[operations/deployment-charts@master] linkrecommendation: Bump version

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

Change 844038 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/deployment-charts@master] Revert "linkrecommendation: Bump version"

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

Change 844038 merged by jenkins-bot:

[operations/deployment-charts@master] Revert "linkrecommendation: Bump version"

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

The swagger patch did not work:

[urbanecm@deploy1002 /srv/deployment-charts/helmfile.d/services/linkrecommendation (master u=)]$ service-checker-swagger staging.svc.eqiad.wmnet https://staging.svc.eqiad.wmnet:4005 -t 2 -s /apispec_1.json
/v1/linkrecommendations/{project}/{domain}/{page_title} (Untitled test) is CRITICAL: Test Untitled test returned the unexpected status 404 (expecting: 200)
[urbanecm@deploy1002 /srv/deployment-charts/helmfile.d/services/linkrecommendation (master u=)]$

Change 844039 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[research/mwaddlink@main] Revert "swagger: Add an example for verifying redirection"

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

Change 844039 merged by jenkins-bot:

[research/mwaddlink@main] Revert "swagger: Add an example for verifying redirection"

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

Etonkovidova subscribed.

Testing notes: when deployed to production verify, for example, the following:

curl -X GET "https://api.wikimedia.org/service/linkrecommendation/v1/linkrecommendations/wikipedia/be-x-old.wikipedia.org/M1_Abrams?threshold=0.5&max_recommendations=3" -H "accept: application/json"

  • presently the above request returns:
400 Undocumented
Error: Bad Request
Response body

  "message": "Unable to process request for wikipedia/be-x-old.wikipedia.org",

Hi @Etonkovidova, perhaps I'm missing something, but I think this URL
address is correct – description mentions
/v1/linkrecommendations/wikipedia/be_x_old/Foo. I think that for your
example, the URL should be
https://api.wikimedia.org/service/linkrecommendation/v1/linkrecommendations/wikipedia/be_x_old/M1_Abrams?threshold=0.5&max_recommendations=3,
which works on my end.

Hi @Etonkovidova, perhaps I'm missing something, but I think this URL
address is correct – description mentions
/v1/linkrecommendations/wikipedia/be_x_old/Foo. I think that for your
example, the URL should be
https://api.wikimedia.org/service/linkrecommendation/v1/linkrecommendations/wikipedia/be_x_old/M1_Abrams?threshold=0.5&max_recommendations=3,
which works on my end.

Thx! My mistake, be-x-old should be be_x_old.

All works as expected.