After this update, a lot of our published apps appear to be now broken. Upon inspecting the metadata for the widget after connecting the affected apps, we noticed that the metadata was stale and not the latest one being forwarded by our MCP servers.
I can confirm that all of them were working until yesterday with no changes to our MCP servers since then.
Happy to dive into this deeper to debug.
I’m the Founding Engineer at Noodle Seed and we have multiple apps accepted and published on the OpenAI Apps store and we are in the midst of marketing campaigns for these apps so a quick resolution would be extremely favorable.
Hi, yes I’d love to understand the issue a bit better. I’m assuming most of the issue will be resolved by pushing your app through an update, so while we work through this I’d recommend getting that kicked off ASAP.
Are you saying that the metadata served by Chat is stale but the current UI relies on changed metadata? If that’s the case, yes, we are only ending caching on this, and changes to CSP/domain limitations are still reviewed for security.
Yeah Chat is currently serving stale metadata including widget template uri, etc. All of our apps are essentially served by a single MCP server but we are noticing that for published apps, the metadata is different across the board including the widget template uri, the csp domains, etc.
We also introduced a cache-busting mechanism for widget template uris that would update a postfixed numeric version if anything was updated in the widget html itself. Our MCP resource endpoint only serves the widget template uri with the latest postfixed numeric version to ensure the latest widget html gets picked up.
I am guessing with the latest updates OpenAI pushed regarding widget html cache-ing this is no longer necessary for published apps?
Should we remove this “cache-busting” mechanism and resubmit new versions for all of our published apps? Doesn’t that mean all of our already published apps will go offline until the latest version is accepted?
Metadata is locked at time of submission, if it’s changed since your submission then that’s cause for concern, otherwise it’s expected!
Not sure what the expected behavior here is, to my knowledge this was never officially supported (I’m new on this area though, so grain of salt). I’d strongly, strongly recommend pushing your apps through the review process here and maintain at least a version of backwards compatibility as you go through the review process.
Our app was accepted and we tested the published app and it was working. All of a sudden, it stopped and the metadata reverted to our first submission (which was rejected due to incorrect CSP).
This doesn’t make any sense. Our submission got rejected multiple times and on every resubmission we updated the metadata in accordance with the reasons supplied in the rejection emails.
In the end, when the app was approved, the metadata for the published app reverted to our first submission (which was rejected).
Hi Saad — thanks for the additional information, and apologies that your latest update did not receive a response.
An approved app initially working and then serving metadata from a rejected submission is not the expected behavior Casey described. Are you still seeing this issue?
If so, please share the affected public app listing URL and the most recent reproduction time and timezone. App IDs, submission/version IDs, conversation links, or other private details should be shared privately through Support. Please provide these information via support request and share the case id here with us so we can track it. Please do not post credentials or sensitive endpoint information here. If everything is now working as expected, or if you need help with anything else, please let us know. Otherwise, once you confirm that no further assistance is needed, we can close the topic. Thanks!