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/

[syphar]

The rebuilds are finished.

Next thing I'll check how many releases failed to rebuild, while their original build succeeded.

So we know how many would actually render wrong when we remove our workaround.

[syphar]

So, I just checked the database.

• There are 1084 releases that were not rebuild in that process,
• 980 when I exclude yanked,
• 797 with rustdoc_status=true, so which previously built

Only looking at latest versions,

• 84 are not rebuilt,
• 62 when I exclude yanked versions,
• 35 when I exclude previously failed builds

The releases I checked just can't be built anymore because the crates or releases they depend on don't exist any more.

So the question for us is:

do we keep the legacy-static-file workaround?

cc @rust-lang/docs-rs

[jyn514]

I'm surprised we have so many failed rebuilds that previously built. Do you have an example crate which failed to rebuild I can look at?

35 latest versions seems very small. I would be ok with removing the hack if it's just those, I think.

[fasterthanlime]

35 latest versions seems very small. I would be ok with removing the hack if it's just those, I think.

I agree with Joshua here!

[syphar]

@jyn514 this is the list, just latest versions that were built, and couldn't be rebuilt.

cratesfyi=> SELECT c.name, r.version , r.release_time
FROM crates as c
INNER JOIN releases  as r on c.latest_version_id = r.id
WHERE r.doc_rustc_version like '%2018-1%' and r.yanked = false and r.rustdoc_status=true order by name;

              name              | version |      release_time
--------------------------------+---------+------------------------
 acme-client                    | 0.5.3   | 2018-08-16 22:02:03+00
 artifact_lib                   | 0.2.1   | 2018-12-23 07:57:43+00
 artifact_serde                 | 0.3.1   | 2018-12-23 07:49:57+00
 asta-jobboerse-api             | 0.1.2   | 2018-10-23 21:00:53+00
 bch                            | 0.1.1   | 2018-11-07 07:44:33+00
 bcrypter                       | 0.1.1   | 2018-10-20 03:20:50+00
 cargo_crates-io_docs-rs_test2  | 0.1.1   | 2018-12-06 02:20:50+00
 chipo                          | 2.1.0   | 2018-11-11 20:38:21+00
 ciruela                        | 0.6.12  | 2018-10-24 13:25:21+00
 crossgen                       | 0.6.0   | 2018-11-06 09:47:16+00
 diesel-geography               | 0.2.0   | 2018-11-24 07:53:44+00
 dynamodb_testcontainer         | 0.1.0   | 2018-12-10 18:01:24+00
 gattii                         | 0.13.0  | 2018-12-01 14:17:43+00
 glib-itc                       | 0.5.0   | 2018-11-16 16:51:52+00
 gtk-fnonce-on-eventloop        | 0.2.1   | 2018-11-17 12:06:18+00
 gw2rs                          | 0.1.0   | 2018-11-11 23:45:34+00
 iron-hmac                      | 0.6.0   | 2018-10-22 23:16:40+00
 nvimpam                        | 0.2.1   | 2018-10-21 19:01:18+00
 oni_simulator                  | 0.1.2   | 2018-10-13 14:31:07+00
 parker                         | 0.0.0   | 2018-11-06 03:47:46+00
 pbp                            | 0.4.0   | 2018-07-20 14:38:08+00
 r2d2-mongodb                   | 0.2.2   | 2019-01-09 18:37:01+00
 rocket-auth-login              | 0.2.3   | 2018-07-20 01:59:45+00
 rocket-lenient-json            | 0.3.1   | 2018-07-12 08:04:41+00
 rustamodb                      | 0.0.6   | 2018-11-18 16:01:39+00
 shopify                        | 0.1.6   | 2018-11-02 15:48:14+00
 sit-core                       | 0.4.1   | 2018-10-02 04:06:11+00
 socket-collection              | 0.4.0   | 2018-12-04 12:54:40+00
 solana-ws                      | 0.2.0   | 2018-12-07 21:41:09+00
 sputnikvm-network-gallactic    | 0.10.1  | 2018-10-24 07:34:20+00
 sputnikvm-precompiled-edverify | 0.1.0   | 2018-10-24 05:05:17+00
 trade                          | 0.1.0   | 2018-10-03 13:21:19+00
 tsukuyomi-server               | 0.2.0   | 2018-12-20 15:29:01+00
 videotoolbox-sys               | 0.0.2   | 2018-11-12 07:53:26+00
 ytr                            | 0.1.1   | 2019-01-07 11:17:40+00
(35 rows)

[syphar]

Seeing the comments here I would propose that in the next axum migration step, which would include the hacked shared-resources-middleware, I leave it out.

It's easy to add again if we need it.

[syphar]

last axum PR is merged, closing this issue now.