Search does not complete

[hellow554]

https://docs.rs/rocket/0.4.0/rocket/?search=foobar gives me:

https://docs.rs/regex/1.1.2/regex/?search=foobar gives me:

[QuietMisdreavus]

I can't reproduce this. Can you check that all the requested resources are loading on your end? Try reloading while bypassing cache (Ctrl-F5), since this fixes some issues on the official docs site.

[hellow554]

I can reproduce it (maybe you should hit ctrl+f5 ;) )

Reproduceable in Firefox, chrome and edge under windows. Even with my mobile and fennec (firefox) and mobile data.

[QuietMisdreavus]

I wonder if it's a CDN thing... I've rebuilt the rocket docs, try reloading again. If it still doesn't work, can you check to see if you can load https://docs.rs/rocket/0.4.0/search-index.js? I want to make sure that you're seeing all the required files.

[hellow554]

Still the same issue. Have you seen, that the console gives me an TypeError?

TypeError: paths is undefined main-20190318-1.35.0-nightly-0f88167f8.js:1:29247

Is there a way to get a non-minified version of main.js?

[QuietMisdreavus]

That version of main.js is available on the rust-lang/rust repo. Chrome can also pretty-print it in the dev tools; i don't know about Firefox.

[hellow554]

Thanks for the hint with the prettification! A french person has the same issue, a US person can see it just fine. It may really be a CDN issue here? Weird.
The thing I noticed it, that there's a discrepancy between the code and the object rawSearchIndex.

Let's take these few lines of code

https://github.com/rust-lang/rust/blob/0f88167f89fffe321590c5148f21b7d51d44388d/src/librustdoc/html/static/main.js#L1556-L1562

They try to access it by .i and .p which the rawSearchIndex[crate] does not have, but instead it has .items and .paths. Maybe that gives you a clue?

[QuietMisdreavus]

If rawSearchIndex has the fields items and paths instead of i and p, then you may have the wrong version of the search index - the search index i'm seeing there has i and p:

@GuillaumeGomez Do you also have this issue? I can't investigate what's going on because i'm not being served the faulty JS.

[GuillaumeGomez]

Nope, works fine for me. Do you add something at the end of the end to be sure users' browsers reload it when needed?

[QuietMisdreavus]

We don't add the resource suffix to the search index, just to the rustdoc static files. We don't touch any of the crate-specific files. The Rocket docs have been successfully built multiple times, so it's completely possible that an older version is being cached somewhere.

[hellow554]

Yep, search index gives me the "old values"

The header for search-index.js is

The date of december 2018 might explain a thing or two. What's in your header?

[hellow554]

Interesting enough curl gives me the correct file. My browser however doesn't.
But this is weird, because even my smartphone didn't show me the correct file and it's on mobile connection.
It shouldn't be a browser issue neither, because I never visited the page with edge nor chrome and I cleared the cache in firefox. What is going on here? :/

[QuietMisdreavus]

I'm getting a date from last month:

I'm 90% sure this is a Cloudfront thing. Docs.rs is being hosted behind Cloudfront, and i bet they're caching the search index and haven't updated it after the docs got rebuilt. The problem now is, i don't know how to tell them to update their caches, either specifically for this file or generally whenever we rebuild any previously-successful docs. 😕

[QuietMisdreavus]

(Unrelated: it's funny that this hit on Rocket's docs, because Sergio would say that you should be using api.rocket.rs for hosted docs instead of docs.rs.)

[hellow554]

One could do the classic trick and append a unrelated query, e.g. search-index.js?2019-03-01 which would give me a correct file right now. :/ I never liked that

[QuietMisdreavus]

Update: it looks like there's a similar issue with URLs that use a partial version number; see this example in tokio. It looks like the tokio/0.1/search-index.js has cached the search index from a previous version of tokio, but the page is using the main.js from the current version, which is expecting the newer/shorter field names in the search index.