When attempting to upsert a metaobject, which is owned by Shopify (toml), we get a few odd behaviours:
1.) The failure: Failed to upsert metaobject for discount 1186074067033: \[{"field":\["handle","type"\],"message":"No metaobject definition exists for type \\"app--9549316097-discount_summary\\"","code":"UNDEFINED_OBJECT_TYPE"}\]
2.) The metaobject definition exists in the admin ui.
3.) The metaobject list shows the incorrect number of instances of that metaobject.
We currently have this error occurring across 7-8 merchants (perhaps more), and they have all followed the same pattern:
1.) Created a metaobject of type app--9549316097-discount_summary
2.) Uninstalled the application with an existing metaobject instance
3.) Reinstalled the application - now they are in a bugged state
The issue is that half of the applications functionality depends on the metaobject(s) existing, and thus this breaks the experience.
I appreciate that this one may be quite difficult/complicated to solve from Shopify’s side, but it would be great to have a procedure to sort out existing instances of this error.
This matches documented behavior, on uninstall Shopify deletes the app-owned TOML metaobject definition but keeps the metaobject entries around for a bit before async cleanup runs. If a reinstall lands after that cleanup already ran, or before your app’s redeploy pushes the definition back, you’ll get exactly this UNDEFINED_OBJECT_TYPE error, and since TOML definitions get a new GID each time they’re recreated, anything still referencing the old definition id stays broken.
Thanks for reporting this, @bkspace. While we investigate the root cause, I’ve sent you a DM asking for the affected shop URLs so we can clear the affected metaobjects on our end and unblock those merchants from using your app.
Hi @releod, the isn’t a fix available yet. We planned a fix earlier, but it’s turned out to require more work than expected. I’ll send you a DM to get the relevant shop URLs and look into unblocking those shops in the meantime.