Service worker serving old versions of custom widgets

[AdamPigg]

We have several custom widgets for Experience Builder as part of our ArcGIS Enterprise.  I have created a new revision of one, and found that the old version is still being loaded by Experience Builder.  I initially though to edit the headers on the server to instruct the client not to cache custom widgets, but this didnt work.  I discovered that the assets are being fulfilled by a service worker as part of ExB.

I know I can clear my cache and have the new assets load, but I dont want to force every user to do this.  Am I missing something that will tell an ExB application when to refresh custom assets?  I have updated the version number in the manifest, but i can see from the network request that the old version is being loaded.

In the browser dev tools, I can see that the custom widgets are part of the exb-assets-cache cache, and that also in this cache is all the other portal content.  It would seem to better to have custom assets handled differently to built-in assets?

Looking through the code, the exb-assets-cache is cleared when the major ExB version changes, eg, 1.10.0.  Perhaps it would be better to clear the cache if the application build number changes?

[AdamPigg]

After much reverse engineering of the compiled ExB code (jimu-core/init.js and service-worker.js) i have came to the following conclusions

• ExB uses a service worker to cache as much as it can
• If the ExB version changes, the cache is cleared
• If the Exb app build number changes the cache is cleared, but this only helps for single instance experiences
• The service worker wont cache:
  • anything with /sharing/rest in the URL
  • version.json in the url
  • Anything from a different origin

The above means that, because our custom widgets are hosted on the same web server as the portal web adapter, they get cached as they have the same origin.  I think there should be a way to control this behaviour, but for now, I hope to be able to update the IIS config to add a port number for the widgets, which will then become a different origin, and then bypass the cache.

[ViktorSafar]

I would correct that the actual string is "/sharing/rest/"

[giorgoskVF]

We are facing the exact same issue and after a lot of research we couldn't find a proper approach to deal with the problem. Asking the users to delete the cache every time we apply some changes in our custom widgets cannot also be the solution. We would really appreciate it,  if someone from ESRI can provide some insights on that matter

[AdamPigg]

So, this is the solution ive gone with....

In IIS, created a new site for hosting widgets, an a different port number - this is treated as a different origin by the service worker and causes the custom widgets to not be cached.

The tedious part, use AGOL Assistant to load the JSON for each widget item, and edit the URI property to point to the new location.

Add a Access-Control-Allow-Origin header for the new "widget" site for the origin used by enterprise.  This allows CORS to work correctly.

This actually seems to work perfectly, even though the old URLs are present in the JSON of the applications (they seem to be ignored, and the URL is taken from the portal item).  It would be nice to see some documentation that states widgets and other custom assets should be hosted on a different origin, but I dont see any,

[Junshan_Liu]

This issue will be fixed in the future release - custom widgets will not be cached in the service worker.

For now, the workaround is not to host the widget in the same domain as the portal.