Hey. What's the cache staleness on the FE? Our clients are complaining data is not updating for them, but when I go to check (first load for me for their WS) I see the updated data, while they don't. The only way to force a refresh is by them clearing their cookies. We already run this every 30 mins, but it doesn't seem to work. We cannot keep asking clients to clear their cookies...

Hi Filip, can you please clarify for me when you go to check (first load for me for their WS) you see the updated data - Do you still fresh data and it’s updated correctly? Or you are also seeing outdated data? If you’re seeing from data all the time, it would seem to suggest that it’s a local issue with clients browser. As mentioned in the following documentation: We recommend automating the notification process so that every time your database is updated, the API or Python function is executed automatically: https://www.gooddata.com/docs/cloud/connect-data/cache-management/reload-cached-data/

I have also noticed it happening when I return to dashboard >1 hour later, even though our cache is dropped every 30 mins via postman. Could this be related to anything in the JWT? How does the FE client know that data has been invalidated and needs to be refreshed?

Hi Filip, Thanks for the follow-up — a few important things to clarify the behavior you're observing: Frontend Cache Staleness & Invalidation While the backend cache (via Postman call every 30 minutes) might be dropping as expected, the frontend still relies heavily on browser-level caching mechanisms, which includes: • Service workers (if used) • LocalStorage or IndexedDB • HTTP cache (with ETag or Cache-Control headers) • Cookies, as you mentioned If the client doesn't perform a hard reload or clear cookies, their browser might still be showing stale data from the cache — especially if the FE doesn’t have a way to detect or react to invalidated backend cache. JWTs typically carry authentication and authorization claims (e.g., user ID, tenant ID, expiration), but they do not carry information about cache invalidation or data freshness. So, it's unlikely that JWTs are directly responsible for telling the frontend to fetch fresh data. However, if FE logic uses token issuance timestamps as a fallback freshness signal, there could be edge cases where a "stale" JWT indirectly contributes to stale UX. Why You See Fresh Data but Clients Don’t When you visit the dashboard for the first time, your browser has no prior cache for that workspace — so you pull fresh data directly. The client, having visited previously, likely has cached metadata or data responses that aren’t purged by the current backend cache drop.

@Joseph Heun I understand that, but what do you suggest we do/check to fix this? Our GD is embedded as an iframe, so I don't think our React can cache it the way you're suggesting.

Hi Filip, I was able to replicate this issue, but I do not believe the authentication method is relevant here. As explained by my colleague, previously, you always need to reload the cached data depending on how your datasource is configured on GoodData side. For instance, I tested this with the "Optimized for speed and savings" cache preference and it was necessary to clear the cache to see the updates from the datasource on the GoodData workspace. This also translated to the iframe. Nevertheless, the setting "Optimize for real-time data" allows to avoid clearing the cache and the updates on the datasource are pushed to the workspace/iframe essentially in real time. With this said, could you please check how the caching settings were set on your datasource and change it to "Optimize for real-time data"? If the issue persists, could you try authenticating with a user with OIDC instead to rule out any issues with the JWT token? If the issue has to do with the JWT token, please provide more details as to how it is generated, and how the iframe is being embedded in your app.

I found the issue. In Postman, we had this running with the old schema

POST {{baseUrl}}/api/v1/actions/dataSources/{data source id}/uploadNotification

. We recently migrated to a new schema in GD and imported that as a new data source. Turns out I forgot to change the cache invalidation runner. Sorry to have wasted your time

Not a problem. I am glad to hear this is solved.