Proactively clear release history XML caches when they're rebuilt

Yes I got that message too. On the Available Updates page, the following text is observed:

Release revoked: Your currently installed release has been revoked, and is no longer available for download. Disabling everything included in this release or upgrading is strongly recommended!

Based on searching for "Release revoked", this issue may resolve itself once the cache clears on drupal.org's server.

I checked manually for updates just now and can confirm I no longer receive the error anymore. The RC now is green and "Up to Date".

Looks like this issue is likely the Drupal.org cache problem.

@puregin check again to see if you get the error now. If not, we should be able to mark this fixed.

Just FYI, this happened probably because you updated to RC1 right after it became available to download but before the update XML feed is refreshed. The XML feed refresh lags behind the package release, I don't know how long but seems like many hours. During that time, you will see the latest release is out-of-date.

#184418: update(_status) results stale for up to 6 hours has been long fixed. The packaging script automatically triggers a rebuild of the release history XML feed for any project that has new releases as soon as it packages anything. I have no idea what happened with the rc1 release that would result in stale info in the core release history feed. True, there's a race condition of maybe a minute or something, but I don't know what we're supposed to do about that. ;)

Maybe the d.o caching system is so over-zealous that update.module was getting stale cached copies of the feeds, even though they had been updated on disk.

Regardless, this isn't a core update.module bug. Moving to the infra queue for further consideration.

I can only think that it might be cached by varnish.

This is most likely a varnish issue. The ttl for updates.drupal.org is already set to 120 seconds in the Varnish config. We need to set up the release script to dynamically purge varnish when new packages are built, but since this should be getting cleared every 2 minutes already, I'm not sure why this would still be happening.

I've made the following changes to see if Varnish wasn't matching the http.host properly. We should still configure varnish to allow dynamic squid style purges (outlined here: http://www.varnish-cache.org/trac/wiki/VCLExamplePurging)

--- a/files/etc/varnish/varnish.vcl/drupal
+++ b/files/etc/varnish/varnish.vcl/drupal
@@ -23,6 +23,11 @@ sub vcl_recv {
         }
     }C
 
+    # clean out requests sent via curls -X mode and LWP
+    if (req.url ~ "^http://") {
+        set req.url = regsub(req.url, "http://[^/]*", "");
+    }
+
     if (req.url ~ ".*/cron.php$") {
         return (pass);
     }
@@ -31,7 +36,7 @@ sub vcl_recv {
     }
 
     # Specific configuration for updates.drupal.org.
-    if (req.http.host == "updates.drupal.org") {
+    if (req.http.host ~ "updates.drupal.org") {
         # Remove the whole query string, that contains the variable site key.
         set req.url = regsub(req.url, "\?.*$", "");
         # Remove any cookie that could be there.
@@ -104,7 +109,7 @@ sub vcl_fetch {
     }
 
    # Specific configuration for updates.drupal.org.
-    if (req.http.host == "updates.drupal.org") {
+    if (req.http.host ~ "updates.drupal.org") {
         set obj.ttl = 120s;
         set obj.cacheable = true;
         return (deliver);

subscribe

I haven't seen this be an issue since around Dec and this thread hasn't had much activity since then.

Should we change this thread's status to closed?

I just applied a security release for a module and am still seeing the Security update required along with the Release revoked message and this is about five minutes later. So, I would say that this is still not fixed.

I just created a new release for a module. 5h later, the feed is still not updated. I created another release (identical, sadly) to see if it would trigger the feed rebuild. But no success, even 3h later.

I have the same problem for another module. Tried the exact same thing, no success, also 5h later.

Look, just ceating another releases won't fix anybody's problem. Why didn't you notify the infra team _before_ doing that? In any case, we've had to rebuild all dev releases, so there was a delay in building the XML feed.

@killes
Because I try to only post a bug-report if I can reproduce the error :-). And I wanted to make sure it was not related to one specific project - for all I knew, I was making a mistake somewhere, preventing it from getting packaged. Just saying "it doesn't work" might not have been very helpful...

But I apologize; next time I'll notify the infra team right away.

Well, it would seem this is still not resolved. Created a new release 4h ago. It's packaged and available on its project page. But the release feed is still not updated. I don't get it. From #8, I take it it should be updated pretty soon afterwards, no ? A few minutes tops.

These are cached in Varnish and the CDN, currently both would need to be cleared.

With #2357551: Update ftp.drupal.org architecture clearing the caches for the packages themselves right away, clearing the XML would be good.

We should migrate updates.drupal.org to Fastly (from EdgeCast) so we can use the same logic for purging these XML releases. That's on the roadmap but will be a few weeks out, there may be some additional work of migrating the updates.drupal.org internally to static1/static2 from the webnodes as well.

Yep, let's wait for that.

In the meantime - research to do:

• The XML is generated by project_release's drush commands. Can we add purging as a post-command hook? I'm not sure if the way packaging invokes the XML generation would get the specific post-command hook, or if enough data would be passed to the post-command hook anyway.
• Otherwise, find or make a hook for drupalorg to implement.

http://updates.drupal.org.global.prod.fastly.net/

This is now configured using static1/static2 instead of the www1-7 webnodes. I've configured this Fastly service to cache all files for 365 days, so the next step here is to configure dynamic cache purging against Fastly similar to how it's set up for http://ftp.drupal.org

Once dynamic purges are happening we can begin testing Fastly fronted updates.drupal.org on some live sites/servers.

For reference, since we'll need to update the Drush configuration for a slightly different log file format, log entries will look like this:

2015-03-20T00:06:45Z cache-sjc3134 fastlyupdates[270882]: 199.127.229.254 | "-" | "-" | 2015-03-20 | 00:06:44 +0000 | GET /release-history/globalredirect/7.x?site_key=dkzlKDFjlskjf-7-ZflkjsdlaIl&version=7.x-1.5&list=globalredirect | 304 | (null) | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0

We should use http://www.fastly.com/blog/introducing-soft-purge/ for purging these, and possibly switch to this for ftp.drupal.org too.

project_release needs to invoke a hook for this.

And drupalorg needs to implement the hook.

This is now deployed.