For the given url http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/styles/ve.init.mw.ViewPageTarget.css

HTP 200
Accept-Ranges:bytes
Access-Control-Allow-Origin:*
Age:2519771
Cache-Control:max-age=2592000
Connection:keep-alive
Content-Length:1232
Content-Type:text/css
Date:Fri, 27 Feb 2015 01:17:46 GMT
ETag:"4d0-50c8b3e7e3800"
Expires:Fri, 27 Feb 2015 21:21:35 GMT
Last-Modified:Tue, 13 Jan 2015 16:37:52 GMT
Server:Apache
Via:1.1 varnish
X-Cache:deployment-cache-bits01 hit (44)
X-Powered-By:HHVM/3.3.0-static
X-Varnish:1048698637 1047370037

HTTP 304
Accept-Ranges:bytes
Access-Control-Allow-Origin:*
Age:2519800
Cache-Control:max-age=2592000
Connection:keep-alive
Content-Type:text/css
Date:Fri, 27 Feb 2015 01:18:15 GMT
ETag:"4d0-50c8b3e7e3800"
Expires:Fri, 27 Feb 2015 21:21:35 GMT
Last-Modified:Tue, 13 Jan 2015 16:37:52 GMT
Server:Apache
Via:1.1 varnish
X-Cache:deployment-cache-bits01 hit (48)
X-Powered-By:HHVM/3.3.0-static
X-Varnish:1048698641 1047370037

When adding a cache-buster query parameter to this url, it returns the latest version properly.

I keep getting stale versions of gadget js, even after clearing local storage.

For http://wikidata.beta.wmflabs.org/wiki/Q12480, I am getting old ext.gadget.AuthorityControl

with debug=true, it works (obviously) to get new javascript and subsequently (assume it is cached in local storage) the gadget works correctly.

We have browser tests for this gadget and it's frustrating that even after updating the gadget to work again with master, the tests fail unless we add "debug=true" or such hacks.

even though the gadget was modified today, the response has "Last-Modified:Thu, 26 Feb 2015 18:21:11 GMT" for:

http://bits.beta.wmflabs.org/wikidata.beta.wmflabs.org/load.php?debug=false&lang=en&modules=ext.PropertySuggester.EntitySelector%7Cext.eventLogging%2CnavigationTiming%7Cext.eventLogging.subscriber%7Cext.gadget.AuthorityControl%2CSiteIdToInterwiki%7Cext.imageMetrics.loader%7Cext.uls.eventlogger%2Cpt%7Cext.wikimediaEvents.statsd%7Cjquery.checkboxShiftClick%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.action.view.postEdit%7Cmediawiki.cookie%2CsearchSuggest%2Ctemplate%7Cmediawiki.page.ready%7Cschema.NavigationTiming%2CSaveTiming%2CUniversalLanguageSelector&skin=vector&version=20150629T182457Z&*

Accept-Ranges:bytes
Age:343901
Cache-control:public, max-age=2592000, s-maxage=2592000
Connection:keep-alive
Content-Encoding:gzip
Content-Length:19218
Content-Type:text/javascript; charset=utf-8
Date:Mon, 02 Mar 2015 17:52:52 GMT
Expires:Sat, 28 Mar 2015 18:21:11 GMT
Last-Modified:Thu, 26 Feb 2015 18:21:11 GMT
Server:Apache
Vary:Accept-Encoding
Via:1.1 varnish
X-Cache:deployment-cache-bits01 hit (4)
X-Content-Type-Options:nosniff
X-Powered-By:HHVM/3.3.1
X-Varnish:1048847910 1048678134

I have merged this task with T65034: Caching makes it impossible to test JS changes when logged out. I have no idea how we handle the bits cache invalidation on production, I thought it had an expiry of 5 minutes with revalidation against the backend, but that is apparently not the case.

This is still the case and still just as frustrating. I forgot that it's been fucked up for months today and tried to test code on beta again.

Change 270443 had a related patch set uploaded (by Krinkle):
resourceloader: Add content hash to static debug urls

https://gerrit.wikimedia.org/r/270443

After T99096, caching these urls for 3 weeks is fine. In fact, it'll be 30 days. Beta Cluster having a special continuous version of "master" is no longer an issue as the new infrastructure will assign a low cache max-age to unversioned resources.

In addition, ResourceLoader debug mode will now actually add content hashes to these urls, so that changes apply regardless of caching - and when there are no changes they fully benefit caching.

Change 270443 merged by jenkins-bot:
resourceloader: Add content hash to static debug urls

https://gerrit.wikimedia.org/r/270443

This change has a side effect for developers using Chrome dev tools workspace feature. The hash value as querystring in resource URL will cause Chrome dev tool not to map it with workspace. This is a bug in Chrome dev tool https://bugs.chromium.org/p/chromium/issues/detail?id=277885

In T90983#2083366, @santhosh wrote:

[…] This is a bug in Chrome dev tool https://bugs.chromium.org/p/chromium/issues/detail?id=277885

Happen to notice this - and it turns out that a few few months after we reported this, Chromium released a reimagined version of their "Workspace" feature which claims to solve for this.

From Chromium bug 277885, comment 52:

DevTools: enable persistence2.0 experiment by default

This patch enables persistence2.0 experiment by default, which results
in the following changes:

• automapping will be enabled by default for all workspace users (Automapping Design Doc)
• a new UI for workspaces will be enabled by default for all workspace users

The document in question calls out lack of tolerance for cache-busting query strings as one of the main flaws in their "old" approach.