Page MenuHomePhabricator

LDF server has 404 errors for JS and CSS resources
Closed, ResolvedPublicBUG REPORT


Steps to Reproduce:

Actual Results:
Refer screenshot

Screen Shot 2019-11-03 at 10.21.58 AM.png (1×1 px, 118 KB)
. Page is white with text listed down page, lacking layout or functionality

Expected Results:

Event Timeline

Looks like css/js artifacts aren't deployed correctly.

Aklapper renamed this task from LDF server broken to LDF server has 404 errors for JS and CSS resources.Nov 3 2019, 7:29 AM

Cannot reproduce on . All four items (page; style.css; logo.svg; favicon.ico) load correctly.

@Aklapper Thanks for the more precise issue title. Attached is a screenshot of 404 errors for minimised js etc. Behaviour is the same across Firefox, Safari, Chrome. Requests are being responded to by cache (server: envoy)

Screen Shot 2019-11-04 at 7.54.20 AM.png (1×2 px, 273 KB)

WikidataFacts added subscribers: Gehel, WikidataFacts.

I think @Ratso56’s original title was more accurate. The core issue isn’t that some JS/CSS is failing to load – as far as I can tell, the server is sending the completely wrong HTML to begin with. It’s sending the same HTML as for (main Wikidata Query Service UI), whereas this is supposed to be a different service.

$ curl -s | sha256sum
343fb7b2a2ef08da29f21dbde5621efdb2ba834371573571715f5da94271e83d  -
$ curl -s | sha256sum
343fb7b2a2ef08da29f21dbde5621efdb2ba834371573571715f5da94271e83d  -

It’s also sending this same HTML regardless of Accept headers:

$ curl -s -H 'Accept: text/turtle' '' | tee >(file -) >(sha256sum) > /dev/null
343fb7b2a2ef08da29f21dbde5621efdb2ba834371573571715f5da94271e83d  -
/dev/stdin: HTML document, ASCII text, with very long lines, with no line terminators

Is the LDF server just gone? What happened here?

Per T232006, the LDF service was still up (though sometimes sending the wrong cached responses) in early September at least.

After some experimentation, I found that this query fails while this query works. The only difference is the order of the URL parameters (in the first, the empty subject is at the beginning, while in the second, it's at the end). No idea what would cause that to matter, though.

For me they look exactly the same – I suspect the first URL is still in your browser cache.

Gehel removed Gehel as the assignee of this task.Jan 7 2020, 2:40 PM

@Vahurzpu Both of those queries fail for me.

from inside any of the WDQS machines ( 'wdqs1004.eqiad.wmnet','wdqs1005.eqiad.wmnet', 'wdqs1006.eqiad.wmnet','wdqs1007.eqiad.wmnet')
the following curls return the correct data
curl localhost:80/bigdata/ldf -> direct to nginx server on host
curl localhost:9999/bigdata/ldf -> direct to query service on host
but curl is not working indicating some problem with routing traffic.
This could be the recent switch from varnish to apache.

Dzahn triaged this task as High priority.Jan 9 2020, 3:39 AM

for clarification the correct response will contain a list that looks like this

@prefix schema: <> .
@prefix pq:    <> .
@prefix pr:    <> .
@prefix ps:    <> .

and the incorrect response is HTML that looks similar to

<!DOCTYPE html><html lang="en" dir="ltr"><head><meta charset="utf-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width,initial-scale=1,user-scalable=yes"><link rel="stylesheet" href="css/style.min.6c0e4865f687302c4d99.css"><link id="favicon" rel="shortcut icon"><script src="js/shim.min.6d0a3b4d4b50e4f73d3e.js"></script><style id="MJX-CHTML-styles">/* placeholder for MathJax */</style></head><body><div class="wikibase-queryservice container-fluid">

Change 563281 had a related patch set uploaded (by BBlack; owner: BBlack):
[operations/puppet@production] Fix WDQS LDF URI routing

Change 563281 merged by BBlack:
[operations/puppet@production] Fix WDQS LDF URI routing

It's consistently working for me now. Thanks!

Thanks @BBlack, this now works as expected.