Nightly rustdoc CSS on doc.rust-lang.org is 404

[dtolnay]

https://doc.rust-lang.org/nightly/std/

According to browser console, it is trying to load https://doc.rust-lang.org/nightly/static.files/rustdoc-bf502f66ec635d5d.css and getting 404.

Oddly, https://doc.rust-lang.org/nightly/core/ works. It uses a different CSS, https://doc.rust-lang.org/nightly/static.files/rustdoc-4e54bb2b497cc83f.css.

The non-working std docs say they are built by 1.77.0-nightly (e51e98d 2023-12-31), while the core docs are built by 1.77.0-nightly (139fb22 2024-01-03).

Other odd things are going on too at the moment. I am not sure how many of these are related or where else to look for issues.

• rustup update nightly is currently serving nightly-2024-01-01, even though the newer rustup update nightly-2024-01-04 is available.
• The two dates in between do not appear to be available.
• None of this is reflected in https://rust-lang.github.io/rustup-components-history/, which cuts off at 2024-01-01

It is currently 7:00 AM in UTC, so not anywhere near the 01:30 AM that rustup nightlies usually go out and standard library documentation gets pushed.

[dtolnay]

Okay the missing nightlies are because no commits landed (#119458 (comment), #119546).

Not sure how this relates to rustdoc CSS.

Maybe this fixes itself tomorrow?

[fmease]

That's a good example though for what breaks when no nightly gets released for a day or two. Ideally this wouldn't have happened even though it seems to have already fixed itself (for me at least the page from first link is properly styled).

I remember that a few months back someone asked on Zulip about precisely this scenario, what would happen if no nightly got released. So maybe it's worth keeping this issue open for an investigation if this can be prevented in the future 🤔.

[GuillaumeGomez]

A lot of pages are still not working, like this one. It definitely would be a nice improvement to prevent this bug in the future. :)

[Mark-Simulacrum]

rust-lang/promote-release#77 is the underlying cause for the current issue. Our html (and tarball) file uploads are not atomic, so there's no guarantee that things will render properly. If the upload completes successfully most people won't notice (since the window of upload is at night - in UTC - and to relatively short), but if it fails then it's much more likely we'll hit problems.

I'm not aware of good things we can do at an infra level to make s3 "deployments" atomic - I think we'd have to come up with a url rewriting scheme, implicit or explicit, that let us atomically flip after writing to new file paths.

[dtolnay]

Looks resolved for now. Standard library docs are now on 1.77.0-nightly (f688dd6 2024-01-04) and have good CSS.