Created an MR and hid the patch. Also changed to apply to the main 11.x branch
Looks like there are some test scripts that still expect an private no-store for aggregated assets. May need to have them adjusted as well.
I did look around and there were some issue potentially related, but did not find anything dealing with this. The closest is the related issue #3427916 which seems to be tackling this through .htaccess change.
I'll work on getting MR with the test script adjustments as well
Added a patch that redirects the old asset url to the new expected url. Should then lead to serving a valid file from the asset directory. Not sure if this is the right approach, but working for us so far.
We are also running into this, and it seems for us the cache control is set to no-store when you request an aggregated file that Drupal does not expect. For example if this is one of the JS requests that drupal generates on page load
/sites/my.site.com/files/js/js_k7uMCXgc43aWXEacSj8oD_I5kXAJJ7IABhs2MRXtPEg.js?scope=footer&delta=3&language=en&theme=transpo&include=eJx1UtF2wyAI_SEXX7b9jgeVJG4oHjDrsq-f6dI2a7cXDtwrcEHwswm4MSFFF1GDpNoSF4t_4y6omol5InRQgNaWgtp7wFQQmATqrG6SFO1dPHjmpr1BfTZ1kamnvsGnq8IBVVlskzRNKO5MGl21YbYeFE3k5kLuLYk90JO2lVKZrvDIpcEJlTO6V3Nt4zyIJL7P6lTR-i_8u1jfSGffbZSlAg17aAITQdXkicO7DSzYX1Yo0e1MH47I_mBPF-wgjZIXkNVekUfZyosEdNplbUt6fHBU-nLVf5_211wv5iPhSe3ZDpnjQnj4vsu0N2RYSl08JZ0xPgopHPtsBF99ns3uPjHE3a1M65iI9jAQqPZq7UIL56SXGgLj7p3Q193dLsj0nL7usx0QdPu2I7Sd6TFuM2b8hWRIZdBKqZmFWspYlp-j11s8Q_bbBcoN4nEMUD5Ah7roHPlUvgHS9kjk
If you change the file name to something random, but keep everything else. Drupal will respond with a 200 and a no-store cache control. example
/sites/my.site.com/files/js/js_RANDOMFILENAME.js?scope=footer&delta=3&language=en&theme=transpo&include=eJx1UtF2wyAI_SEXX7b9jgeVJG4oHjDrsq-f6dI2a7cXDtwrcEHwswm4MSFFF1GDpNoSF4t_4y6omol5InRQgNaWgtp7wFQQmATqrG6SFO1dPHjmpr1BfTZ1kamnvsGnq8IBVVlskzRNKO5MGl21YbYeFE3k5kLuLYk90JO2lVKZrvDIpcEJlTO6V3Nt4zyIJL7P6lTR-i_8u1jfSGffbZSlAg17aAITQdXkicO7DSzYX1Yo0e1MH47I_mBPF-wgjZIXkNVekUfZyosEdNplbUt6fHBU-nLVf5_211wv5iPhSe3ZDpnjQnj4vsu0N2RYSl08JZ0xPgopHPtsBF99ns3uPjHE3a1M65iI9jAQqPZq7UIL56SXGgLj7p3Q193dLsj0nL7usx0QdPu2I7Sd6TFuM2b8hWRIZdBKqZmFWspYlp-j11s8Q_bbBcoN4nEMUD5Ah7roHPlUvgHS9kjk
This is an issue for us because we have a use case where other sites reference our assets and may not have the update js/css aggregated links right away. And this causes a lot of uncached requests hitting all the way to origin. Specifically if those sites have bots crawling them
We had to account for when the views area was added to the "No results behavior" section of the view. Adjusted the patch for this
I've added a patch that resolve the issue for us
Is there a way to get a patch/fix for this on 10.2.x?
We're running into this issue ourselves.
Narrowed it down to the following line in core/misc/states.js changing from
const $states = $(context).find('[data-drupal-states]');
to
const elements = once('states', '[data-drupal-states]', context);
due to the the fix in
https://www.drupal.org/project/drupal/issues/3347144
🐛
Form API #states property/states should use .once() to apply its rules (Can cause failures with BigPipe and possibly other situations)
Needs work
We have a temporary fix at the moment with a custom patch that changes
const elements = once('states', '[data-drupal-states]', context);
back to
const elements = $(context).find('[data-drupal-states]');
We're using this until someone comes up with a better patch.