# Custom kibana plugins will not update due to client side resource caching **URL:** \ **Category:** Kibana\ **Tags:** kibana-plugin-development\ **Created:** [March 15, 2021, 12:36am UTC](https://discuss.elastic.co/t/custom-kibana-plugins-will-not-update-due-to-client-side-resource-caching/267207 "2021-03-15T00:36:22Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Tobias\_H](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tobias_h/32/80037_2.png) [@Tobias\_H](https://discuss.elastic.co/u/Tobias_H)\ **Post date:** [March 15, 2021, 12:36am UTC](https://discuss.elastic.co/t/custom-kibana-plugins-will-not-update-due-to-client-side-resource-caching/267207/1 "2021-03-15T00:36:22Z")
I'm using kibana 7.10.2, which includes the latest improvements to the packaging scripts `@kbn/plugin-helpers`: > to build production 3rd kibana plugins using the new architecture: > **[Introducing a new architecture for Kibana | Elastic Blog](https://www.elastic.co/fr/blog/introducing-a-new-architecture-for-kibana)** > > We’ve been working on a re-architecturing of Kibana that will make it easier to add new features more quickly, both for Elastic developers and the wider community. Here’s why we took this project on and what it means for developers now. 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-revalidate`and `ETag` are used to ensure client side JS bundels are uptodate: [https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching) However when deploying to production: > **[Kibana plugins | Kibana Guide \[7.11\] | Elastic](https://www.elastic.co/guide/en/kibana/current/kibana-plugins.html#install-plugin)** `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? ---
**Author:** ![tsullivan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tsullivan/32/31077_2.png) [@tsullivan](https://discuss.elastic.co/u/tsullivan)\ **Post date:** [March 17, 2021, 5:38pm UTC](https://discuss.elastic.co/t/custom-kibana-plugins-will-not-update-due-to-client-side-resource-caching/267207/2 "2021-03-17T17:38:11Z")
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`) ---
**Author:** ![Tobias\_H](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tobias_h/32/80037_2.png) [@Tobias\_H](https://discuss.elastic.co/u/Tobias_H)\ **Post date:** [March 18, 2021, 2:58pm UTC](https://discuss.elastic.co/t/custom-kibana-plugins-will-not-update-due-to-client-side-resource-caching/267207/3 "2021-03-18T14:58:13Z")
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 ```auto 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. ---
**Author:** ![tsullivan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tsullivan/32/31077_2.png) [@tsullivan](https://discuss.elastic.co/u/tsullivan)\ **Post date:** [March 18, 2021, 5:02pm UTC](https://discuss.elastic.co/t/custom-kibana-plugins-will-not-update-due-to-client-side-resource-caching/267207/4 "2021-03-18T17:02:01Z")
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](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](https://github.com/elastic/kibana/issues/94951) ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 15, 2021, 5:02pm UTC](https://discuss.elastic.co/t/custom-kibana-plugins-will-not-update-due-to-client-side-resource-caching/267207/5 "2021-04-15T17:02:43Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.