{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif4qa55n7i4qrhm5qjtyrl2pc5if5enblcvwcjyng7degcmsc776y",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3ml374lf73m52"
  },
  "path": "/t/production-update-workflow-widget-uris-cache-keys-best-practices/1380116#post_4",
  "publishedAt": "2026-05-05T02:26:27.000Z",
  "site": "https://community.openai.com",
  "textContent": "Thanks for these responses.\n\nHere is what worked for me. A stable URI in tools/list going forward, plus a ResourceTemplate catching legacy versioned URIs, all resolving to current widget HTML.\n\n\n    server.registerResource('show_venues', 'ui://widget/show-venues.html', {}, handler);\n\n\n`server.registerResource(`\n\n` 'show_venues-legacy',`\n\n` new ResourceTemplate('ui://widget/show-venues-{version}.html', { list: undefined }),`\n\n` {},`\n\n` handler,`\n\n`);`\n\nThe template absorbs cached clients still pinned to old versioned URIs - this immediately fixed my production app.\n\nWorth noting: my previous setup did bake a per-build version into every advertised URI. The clean version of that pattern — retain all old widget HTML _and_ the static chunks each version references — is hard in Next.js (which is what I’m in). Every `next build` regenerates the `_next/static/` hashes, so old HTML pointing at old chunks 404s after the next deploy. Stable URI + template catch was the pragmatic path.\n\nMy plan is when I make changes that aren’t backward-compatible (parameter shape, behavior), I’ll bump to a new URI, keep the old URI registered against the old handler, and only advertise the new one in tools/list. Old chats pinned to the old URI keep working with the old code; new chats get the new contract.\n\nThis is assuming tools/list is snapshotted at submission and only updated on approved resubmission… which I’m pretty sure is the case  but if anyone knows otherwise please share!\n\nThanks again!",
  "title": "Production update workflow, widget URIs, cache keys - best practices"
}