Docs built during 2018-{10-12} link to the wrong url for static resources

[Nemo157]

Noticed by @fasterthanlime: https://twitter.com/fasterthanlime/status/1328374357689765890

An example doc page: https://docs.rs/druid/0.1.1/druid/index.html

All docs built with these rustc versions hit the issue:

prod-dump=# select distinct doc_rustc_version from releases where doc_rustc_version like '%2018-1%';
              doc_rustc_version
---------------------------------------------
 rustc 1.32.0-nightly (3e90a12a8 2018-11-29)
 rustc 1.33.0-nightly (adbfec229 2018-12-17)
 rustc 1.32.0-nightly (6b9b97bd9 2018-11-15)
 rustc 1.31.0-nightly (78ff609d7 2018-10-19)
(4 rows)

The issue is that these include bad paths to the static resources:

<link rel="stylesheet" type="text/css" href="../normalize-20181019-1.31.0-nightly-78ff609d7.css">

Previously this worked because the static file handler ignored the path, and just served these static resources from any directory if the filename matched, which I recently fixed: d8caa1c

This affects 14k releases, of which 3k were the latest version of a crate as of 7 months ago (which is the dataset I have available)

prod-dump=# select count(*) from releases where doc_rustc_version like '%2018-1%';
 count
-------
 14298
(1 row)

prod-dump=# select count(*) from (select doc_rustc_version, rank() OVER (PARTITION BY crate_id ORDER BY id DESC) as rank from releases) as _ where rank = 1 and doc_rustc_version like '%2018-1%';
 count
-------
  2929
(1 row)

prod-dump=# select max(release_time) from releases;
         max
---------------------
 2020-04-27 14:13:00
(1 row)

[Nemo157]

We could probably revert d8caa1c for now, that will result in us serving rustdoc's version of the font files instead of our own (because they have the same names but are hosted in different directories), but that should be fine since they're the same fonts.

[jyn514]

Eventually we should rebuild all these crates not to be buggy, but since there's 14k of them I think reverting in the meantime makes sense.

[jsha]

This affects 14k releases, of which 3k were the latest version of a crate as of 7 months ago (which is the dataset I have available)

Could you re-run the query again to find out how many affected builds are currently the latest version? If it was 3k in April 2020 I'm guessing it's much lower now. It is probably practical to rebuilt that subset and allow the non-latest builds to have broken CSS.

[jyn514]

@jsha still pretty high

cratesfyi=>  select count(*) from (select doc_rustc_version, rank() OVER (PARTITION BY crate_id ORDER BY id DESC) as rank from releases) as _ where rank = 1 and doc_rustc_version like '%2018-1%';
 count 
-------
  1770
(1 row)

[syphar]

@Nemo157 @jyn514

INSERT INTO queue (name, version, priority, registry)
SELECT c.name, r.version , 10, ''
FROM crates as c
INNER JOIN releases  as r on c.id = r.crate_id
WHERE r.doc_rustc_version like '%2018-1%'
ON CONFLICT (name, version) DO UPDATE
SET priority = EXCLUDED.priority,
    registry = EXCLUDED.registry,
    attempt = 0

This would be the rebuild / requeue statement, am I missing something?

[jyn514]

Yes, that looks right :) I think it will rebuild slightly more crates than needed but I don't think it's worth looking up the exact dates.

[syphar]

I just ran the statement, all these releases are requeued now.

I chose priority 20, which didn't have any entries in the queue before, so we can easily remove these again if there was any mistake.

[syphar]

example for first successful rebuilds:

• https://docs.rs/finite-field/0.0.0/finite_field/
• https://docs.rs/argmin_codegen/0.1.6/argmin_codegen/