Debugging incorrectly-empty responses from self-hosted polyfill-service

[mq2thez]

Hey folks,

My team runs a self-hosted version of the polyfill-service (v4.46.0) in Google Cloud, and we recently discovered (via Sentry errors) a large number of mobile Safari users not properly getting IntersectionObserver polyfills.

After some investigation in our backend logs, we've discovered a number of these users getting empty responses which contain just:

/* Polyfill service v3.110.1
 * Disable minification (remove `.min` from URL path) for more info */

In my case, I can reproduce this by spoofing a Mobile Safari 14 UA string with curl:

$ curl -A "Mozilla/5.0 (iPhone; CPU iPhone OS 15_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Mobile/15E148 Safari/604.1" "https://www.etsy.com/paula/v3/polyfill.min.js?etsy-v=v3&flags=gated&ua-hash=22566b90142c045298f97c23ce0287c3&features=AbortController%2CArray.from%2CArray.of%2CArray.prototype.@@iterator%2CArray.prototype.copyWithin%2CArray.prototype.fill%2CArray.prototype.find%2CArray.prototype.findIndex%2CArray.prototype.flat%2CArray.prototype.flatMap%2CArray.prototype.includes%2CCustomEvent%2CDOMTokenList.prototype.@@iterator%2CElement.prototype.append%2CElement.prototype.classList%2CElement.prototype.closest%2CElement.prototype.matches%2CElement.prototype.remove%2CElement.prototype.replaceWith%2CIntersectionObserver%2CIntersectionObserverEntry%2CMap%2CNodeList.prototype.@@iterator%2CNodeList.prototype.forEach%2CNumber.Epsilon%2CNumber.MAX_SAFE_INTEGER%2CNumber.MIN_SAFE_INTEGER%2CNumber.isFinite%2CNumber.isInteger%2CNumber.isNaN%2CNumber.isSafeInteger%2CNumber.parseFloat%2CNumber.parseInt%2CObject.assign%2CObject.entries%2CObject.fromEntries%2CObject.getOwnPropertyDescriptors%2CObject.is%2CObject.preventExtensions%2CObject.setPrototypeOf%2CObject.values%2CPromise%2CPromise.prototype.finally%2CRegExp.prototype.flags%2CSet%2CString.fromCodePoint%2CString.prototype.@@iterator%2CString.prototype.anchor%2CString.prototype.codePointAt%2CString.prototype.endsWith%2CString.prototype.includes%2CString.prototype.padEnd%2CString.prototype.padStart%2CString.prototype.repeat%2CString.prototype.startsWith%2CString.raw%2CSymbol%2CSymbol.hasInstance%2CSymbol.isConcatSpreadable%2CSymbol.iterator%2CSymbol.match%2CSymbol.replace%2CSymbol.search%2CSymbol.species%2CSymbol.split%2CSymbol.toPrimitive%2CSymbol.toStringTag%2CSymbol.unscopables%2CURL%2CWeakMap%2CWeakSet%2Cfetch%2Clocation.origin%2CmatchMedia"

/* Polyfill service v3.110.1
 * Disable minification (remove `.min` from URL path) for more info */

According to our backend logs, these no-polyfill responses are being logged as 204 No-Content response codes. I haven't been able to determine what part of the polyfill-service stack would cause a 204 to be served, though I combed through a number of the sub-dependencies.

What's extremely odd about this is that changing our "cache-buster" query param, etsy-v, to a "new" value, like etsy-v=v7 and changing nothing else causes the service to start returning polyfills correctly (for this UA string, I'd expect to get the IntersectionObserver polyfill only). The issue also seems somewhat intermittent -- I can see in our logs that for some requests, the polyfills are served correctly (denoted by the KB size of the response in our logs).

Does anyone have any recommendations on what steps we could take to determine what's going on here? I'm fairly stumped as to what might be causing this, and it's becoming a bit concerning to us that the IntersectionObserver polyfill being missing might just be the tip of the proverbial iceberg in terms of users on older browsers not properly getting polyfills.