Hi, I am developing some widgets. They are served up from a development server.
using chrome as the client.
Having issues getting the latest widgets off the development server, sometimes they are a few versions behind (cached).
I have tried “refreshing”, disconnect/reconnect , private browser and I get sporadically different levels of cached widgets . I have also tried deleting “application” data.
Any help on how I avoid these issues , pls?
Sorry what does “This post was flagged by the community and is temporarily hidden.” mean? Why would it be flagged?
It means a post (reply) was flagged and resulted in the post being hidden, which means moderators and above can see the reply but for most it is hidden. The post has not been deleted.
If a moderator decides the flag is valid, then one of several actions can occur.
In your case it means you see that a reply exist but not the details.
Since I can read the reply, all I can say is that flagging was a wise decision.
Have you tried implementing Cache Busting for your widget resource URLs on the server?
I ran into the same issue while testing widget changes, so I implemented hash/version calculation based on the widget code. The resources are served like this:
ui://widgets/summary.html?v=c221706e114f3023
On my server, even a small layout change regenerates the hash on re-init, so after a “refreshing” new hashes are generated and the UI will always fetch the fresh content instead of a cache.
THanks.
yes. I included an epoch time stamp , so when you “refresh” it changes the widget url and I can see them in the settings.
Update: SOLVED, I think/hope: I was only including the “bust” in eacg tool/template url.. but I just noticed it was not in the other “template” url (further down the page). So that seems to have fixed it .
I also includes some no-cache directives in the MCP url too, but I don’t think that solved it.
Thanks for the help
Thanks for coming back to share the solution with the community!
Hoping this helps someone in the future!
no worries. Paul… mmm issue started happening again 
so it seems like I had somehow flushed the cashe… I managed to flush it a few times, but it’s still not 100% consistent
Take a look at my post here:
I’ve seen this too. The most reliable fix seems to be “version the widget URI”, not just the underlying HTML assets.
Two patterns that helped:
If you do (2), treat every deploy as a new widget version (scripted bump).
We were also trying to solve this issue but without success. Then we noticed there is the ChatGPT app refresh button in the App settings which pulls the new tool widget HTML resources.
Hey @Jakub_Kopecky, good catch on the Refresh option in App settings.
New actions don’t auto update, so yeah, hitting that button helps pull in MCP server changes. This is also mentioned in this Help article. Quick question though, did that successfully update the widget on the browser?
One more thing, if you make breaking changes to your widget’s HTML, JS or CSS, it’s best to give the template a new URI (or rename the file). That forces ChatGPT to load the fresh bundle instead of a cached version as as mentioned in this Dev Doc.
Updating the widget URI does work only if i click the Refresh button, what about publicly published app to the Apps Directory . I don’t see a way for us to Refresh that
So from what I’ve experienced - you have to submit another version - during the submission process, you click on a Scan Tools button during the process- that particular piece seems to pull in a locked cache of your MCP assets at that point in time. I learned this the hard way - we submitted our approved app and had made some minor fixes to our MCP during the Review process where we removed from Review but never clicked “Scan Tools” again - I believe that will trigger it - you should still version your widgets though just like mentioned above. That should pull in a version number on your html so you can verify once published. IT sucks you can’t see that though on the Submission flow - I have no way to see my cache bust value pulling into their flow during that process. That would be a huge improvement