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.

[QuietMisdreavus]

cc rust-lang/rust#59776 (comment)

That PR suggests to start adding the resource suffix to the search index, which will sidestep the issue by making newer builds request a different URL for it. That will solve the Rocket issue, and this specific problem of main.js and search-index.js using different versions of the index structure.

However, i proposed a different solution in the linked comment: We should never serve docs on a URL that doesn't use an exact version number. Any URLs with a semver requirement instead of a version number should issue a redirect to the latest matching version. This solves the tokio issue by always requesting the newest version instead of sneakily changing tokio/0.1/search-index.js underneath the CDN.

However, now that i'm typing this up here, i see that that doesn't fix the Rocket problem, so maybe the complete solution is to do both this proposal and that PR. 🤔

[galich]

Seems like similar or same problem happens with tokio now:

https://docs.rs/tokio/0.1.18/tokio/ - search works
https://docs.rs/tokio/0.1.19/tokio/ - search does not work

browser console is full of

Blocked loading mixed active content “http://docs.rs/tokio/0.1.19/tokio/”
The script from “https://docs.rs/tokio/0.1.19/search-index-20190417-1.36.0-nightly-3c3d3c177.js” was loaded even though its MIME type (“”) is not a valid JavaScript MIME type.[Learn More]

tokio-rs/tokio#1059

[elomatreb]

Running into this on the actix-web docs. This has a string in the version number (1.0.0-beta), maybe something is broken with that?

[Dushistov]

Looks like these happens for all recent versions of crates, see also https://internals.rust-lang.org/t/docs-rs-search-is-broken/9906 , search in previous versions of the same crate works fine.

[QuietMisdreavus]

The issues with recent crates' search indexes failing to load should be fixed by #329.

[QuietMisdreavus]

#329 has been deployed, recent crates should be able to complete searches now. I'll post in the internals thread about what went wrong.

[galich]

it works for https://docs.rs/tokio/0.1.19/tokio/

[QuietMisdreavus]

I've just opened #342 to redirect version-catchall URLs to the full version number, which should fix this issue tokio had in #316 (comment), and close this issue entirely.