Open d33t opened 1 year ago
iirc this problem normally only occurs in development context, e.g. you develop your application locally, change the caconfig definition and redeploy our bundle and then you run into this problem if you keep your browser session.
it should normally not be a problem in production with normal deployment cycles? please report back if it's otherwise.
in general, we will check if this can be improved, e.g. by detecting changes in the caconfig definition via a timestamp or hash.
Thanks for your input. In a real world scenario, it could also happen when deploying new release and the user/author is hard working the whole day and thus keeps it's browser session active in the worst case until the token expires after 12 hours. One would expect that this might refresh the session storage, but actually it lives as long as you keep the same tab/window open. So from my understanding as long as the author uses every day the same browser tab and never closes it, the issue will last for long period of time, longer after the new release is performed. Not tested, but just thinking about it.
A page session lasts as long as the tab or the browser is open, and survives over page reloads and restores.
https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage
i've seen this problem in the past, but could not reproduce this issue today with a local AEM instance (tested with AEM 6.5 and AEMaaCS SDK, and latest chrome browser).
can you add you steps to reproduce, and the environment you've used?
When an existing configuration is changed (e.g. property added, removed, whatever) and a new version is deployed, the CA editor doesn’t show the modifications because the configuration is cached in the session storage (property name: caconfig-configCache). The issue gets resolved if the local browser data or the property is removed or the browser session gets invalidated.