{"id":"6a381578b8fa95e90c02d4f7","title":"2026 06 21 Build 713","path":"how-to/committee/release-notes/2026-06-21-build-713","contentMarkdown":"# 21-Jun-2026 — build the push service worker in the image, harden Google Cloud setup, and make push de... [#293](https://github.com/nbarrett/ngx-ramblers/issues/293)\n\n## [build 713](https://github.com/nbarrett/ngx-ramblers/actions/runs/27910715314) — [commit 63fc039](https://github.com/nbarrett/ngx-ramblers/commit/63fc03946e9585275d0b18c676855afc436831b5)\n\n_____\n\nFollow-ups to the Gmail inbox work, found testing on staging and EKWG:\n\n- Dockerfile: the image build ran `npx ng build` directly, which skips the\n`prebuild` npm hook that compiles inbox-push-sw.ts into dist-sw/. The Angular\nasset copy then had nothing to copy, so /inbox-push-sw.js returned 404 in every\ndeployed image and the inbox web-push service worker failed to register (it\nonly worked locally, where `npm run build` triggers `prebuild`). The image\nbuild now runs `npm run build:sw` before `ng build`.\n\n- inbox-google-setup: setup is now resilient on a project where the required\nAPIs are not already enabled. It enables the Cloud Resource Manager, Gmail and\nPub/Sub APIs and resolves the project's canonical ID via Resource Manager.\nGoogle's API enablement takes a few minutes to propagate, so the project\nlookup and the Pub/Sub steps (create topic, grant publisher, create push\nsubscription) now retry with backoff over roughly 2.5 minutes when they hit\nthe \"API has not been used before or is disabled\" error, instead of failing.\nCrucially, the topic and subscription are now named with the project ID rather\nthan the project number: Gmail's users.watch validates the topic name against\nthe project ID, so the number-form name was rejected (\"Invalid topicName does\nnot match projects/<id>/topics/*\") even though Pub/Sub itself accepts the\nnumber. This also corrects the stored pubsubProjectId from the display name to\nthe real ID.\n\n- system-inbox-mailbox-connections: switching a mailbox to push now always\nre-fetches the configured Pub/Sub topic before applying the watch, rather than\ntrusting a cached value that can be stale right after setup (which completes in\nthe background). So push applies with the correct topic without a manual page\nrefresh.\n\n- inbox-notification.service: the header unread badge now wires its websocket\nsubscriptions before connecting (and relies on the client's own reconnect), so\na failed or dropped initial connection - e.g. while a deploy restarts the app -\nno longer leaves the badge without a live feed. It picks up the next event and\nupdates without a page refresh.","contentHtml":"<h1>21-Jun-2026 — build the push service worker in the image, harden Google Cloud setup, and make push de... <a href=\"https://github.com/nbarrett/ngx-ramblers/issues/293\">#293</a></h1>\n<h2><a href=\"https://github.com/nbarrett/ngx-ramblers/actions/runs/27910715314\">build 713</a> — <a href=\"https://github.com/nbarrett/ngx-ramblers/commit/63fc03946e9585275d0b18c676855afc436831b5\">commit 63fc039</a></h2>\n<hr>\n<p>Follow-ups to the Gmail inbox work, found testing on staging and EKWG:</p>\n<ul>\n<li><p>Dockerfile: the image build ran <code>npx ng build</code> directly, which skips the\n<code>prebuild</code> npm hook that compiles inbox-push-sw.ts into dist-sw/. The Angular\nasset copy then had nothing to copy, so /inbox-push-sw.js returned 404 in every\ndeployed image and the inbox web-push service worker failed to register (it\nonly worked locally, where <code>npm run build</code> triggers <code>prebuild</code>). The image\nbuild now runs <code>npm run build:sw</code> before <code>ng build</code>.</p>\n</li>\n<li><p>inbox-google-setup: setup is now resilient on a project where the required\nAPIs are not already enabled. It enables the Cloud Resource Manager, Gmail and\nPub/Sub APIs and resolves the project&#39;s canonical ID via Resource Manager.\nGoogle&#39;s API enablement takes a few minutes to propagate, so the project\nlookup and the Pub/Sub steps (create topic, grant publisher, create push\nsubscription) now retry with backoff over roughly 2.5 minutes when they hit\nthe &quot;API has not been used before or is disabled&quot; error, instead of failing.\nCrucially, the topic and subscription are now named with the project ID rather\nthan the project number: Gmail&#39;s users.watch validates the topic name against\nthe project ID, so the number-form name was rejected (&quot;Invalid topicName does\nnot match projects/<id>/topics/*&quot;) even though Pub/Sub itself accepts the\nnumber. This also corrects the stored pubsubProjectId from the display name to\nthe real ID.</p>\n</li>\n<li><p>system-inbox-mailbox-connections: switching a mailbox to push now always\nre-fetches the configured Pub/Sub topic before applying the watch, rather than\ntrusting a cached value that can be stale right after setup (which completes in\nthe background). So push applies with the correct topic without a manual page\nrefresh.</p>\n</li>\n<li><p>inbox-notification.service: the header unread badge now wires its websocket\nsubscriptions before connecting (and relies on the client&#39;s own reconnect), so\na failed or dropped initial connection - e.g. while a deploy restarts the app -\nno longer leaves the badge without a live feed. It picks up the next event and\nupdates without a page refresh.</p>\n</li>\n</ul>\n"}