Custom kibana plugins will not update due to client side resource caching

[Tobias_H]

I'm using kibana 7.10.2, which includes the latest improvements to the packaging scripts @kbn/plugin-helpers:

[plugin-helpers] improve 3rd party KP plugin support

to build production 3rd kibana plugins using the new architecture:

Introducing a new architecture for Kibana | Elastic Blog

We noticed that when launching the plugins in developement mode yarn start --oss that any changed plugin resource will be immediately updated in your browser. That's what you expect of a dev mode. This works as cache-control header is set to must-revalidateand ETag are used to ensure client side JS bundels are uptodate:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

However when deploying to production:

Kibana plugins | Kibana Guide [7.11] | Elastic

cache-control header is set up 1 year and packaged JS resources keep the same name / url. That means even after restarting kibana server side client's won't see the latest version of a 3rd party plugin.

ETags still require a roundtrip to validate the resources. Therefore the preferred solution would be to enable fingerprinting. Is there any infrastructure available build into kibana to use for that purpose? How do we enable that?

[tsullivan (Tim Sullivan)]

Hi how are these resources imported in the code? Files such as JS files should be imported via webpack so they become part of your plugin bundle(s). That way, the resource URL has a cache-busting random number in the URL. (e.g the 39000 in localhost:5601/39000/bundles/plugin/discover/discover.plugin.js)

[Tobias_H]

All files are part of the plugin bundle(s) already. The situation is that the cache-busting random number seems to be not updated across cycles of

    kibana-plugin remove myplugin
    kibana-plugin install myplugin.zip

Regarding the mentioned discover.plugin.js this file is present flat on the filesystem (apart from .gz and brotli compressed version):
/usr/share/kibana/src/plugins/discover/target/public/discover.plugin.js
When this file is accessed the cache busting key gets computed to
http://localhost:5601/36136/bundles/plugin/discover/discover.plugin.js
The discover plugin is obviously part of the basic kibana stack. The interesting aspect here is that our own plugin data receives the same cache busting key:
http://localhost:5601/36136/bundles/plugin/myplugin/myplugin.plugin.js
Therefore if the ELK stack sticks at a specific version, but the 3rd party plugin get's updated, then the cache busting key stays the same, which leads to a dirty client cache.

If the cache-busting key would be computed based on the underlying data (e.g. hash of data content), then it would immediately work. Therefore: How can we enforce to get the cache busting key updated? Ideally it should be computed based on content. Second option would be plugin name + version. But since the same key used even for ELK core plugins (e.g. discover) updating anything in the 3rd party plugin wouldn't be sufficient.

[tsullivan (Tim Sullivan)]

It sounds like you have found a need for an enhancement in Kibana's bundling system. Your suggestions would be useful to bring up in an enhancement ticket in Github: https://github.com/elastic/kibana/issues/new?assignees=&labels=&template=Feature_request.md

I went ahead and filed this issue: [Webpack] The numeric prefix for cache busting in URLs to static resources does not change even if plugin code changes · Issue #94951 · elastic/kibana · GitHub