`https://docs.rs/futures-concurrency/latest/futures_concurrency/` is stale

[scottlamb]

When I load https://docs.rs/futures-concurrency/latest/futures_concurrency/ I see version 6.0.1, even if I use Chrome dev tools to disable my browser's cache.

response headers:

age: 78002
alt-svc: h3=":443"; ma=86400
content-encoding: gzip
content-type: text/html; charset=utf-8
date: Thu, 17 Nov 2022 00:56:29 GMT
server: nginx/1.14.0 (Ubuntu)
vary: Accept-Encoding
via: 1.1 bf7159e30a38421f642619d6da9a8eb4.cloudfront.net (CloudFront)
x-amz-cf-id: 3y6ebsTcpSWEqI8LuMKQ9oyVgKPwhFB4FPuxbQco8XXkWmm6wUUaAQ==
x-amz-cf-pop: IAD12-P2
x-cache: Hit from cloudfront

Version 7.0.0 was released 21 hours ago, according to https://docs.rs/releases/recent/32 (long enough ago that I had to hit next a bunch to find it!).

Ahh here's the build: https://docs.rs/crate/futures-concurrency/7.0.0/builds/674685

7.0.0 shows up in search and takes me to https://docs.rs/futures-concurrency/7.0.0/futures_concurrency/ which looks as I'd expect. Its headers:

age: 19452
alt-svc: h3=":443"; ma=86400
cache-control: stale-while-revalidate=86400
content-encoding: gzip
content-type: text/html; charset=utf-8
date: Thu, 17 Nov 2022 17:12:56 GMT
server: nginx/1.14.0 (Ubuntu)
vary: Accept-Encoding
via: 1.1 b7f525be96cecf61bbec66a423b622b0.cloudfront.net (CloudFront)
x-amz-cf-id: 2bKT_Q6Jz_-KIk6ayeMz7Q1NjbK4RlUsjGbgWEN64hRHRGjsT-OHPw==
x-amz-cf-pop: IAD12-P2
x-cache: Hit from cloudfront

I see mention of CDN invalidations in other issues. E.g. #1877 says they take up to 15 minutes. That's well past, so is it possible that step got entirely skipped for this release for some reason?

[Nemo157]

It definitely looks like an invalidation issue, the date is from a couple minutes before the build completed and the path should have been invalidated. Looking through a couple more recent crates I found https://docs.rs/testdir/latest/testdir/ which similarly isn't updated (for the datacenter I hit at least).

We don't have any errors being logged from the invalidations and at a glance it seems to be configured correctly, but I don't know whether we have any other tools to see if the invalidations are being processed correctly. Hopefully @syphar has some ideas what to look at.

[syphar]

Thank you for reporting this!

This is really very odd. We don't see any error in the logs, so creating the invalidation request with CloudFront succeeded.

The only possible explanation I have is that somehow the invalidation failed, since we don't query & check the invalidation status yet.

Currently the CDN caches only for a day, so the pages should be up-to-date now (@scottlamb please ping me if they are not up-to-date now for you, then I'll manually invalidate again).

I'll check with infra about CloudFront if they can see any failed invalidations, possibly then reducing the caching time again, and/or writing code to check & retry the invalidations.

[syphar]

related discussion: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/docs.2Ers.20.2F.20more.20CloudFront.20caching

[syphar]

Since #1961 we have an invalidation queue & reporting on it.

We are running with a one-day TTL for some weeks already, so I'm closing this issue as solved.