DEV Community: Matt Fauveau

Waking a dead service worker with Web Push, from a Cloudflare Worker

Matt Fauveau — Wed, 29 Jul 2026 02:38:45 +0000

Last time I wrote about keeping a WebSocket alive inside a Manifest V3 extension, and the whole trick was staying awake: heartbeats, reconnects, guards. That solved the session that's already running. It did nothing for the case that actually matters most to a planning-poker tool, which is the teammate who isn't there yet.

Here's the moment. The facilitator points a ticket in Repoker. Three people are in the room. The fourth is deep in an editor somewhere, no GitHub tab open, no room open, nothing. The team either waits or pings them on Slack, which is exactly the busywork this tool exists to remove. I wanted their machine to just... tap them on the shoulder.

You can't hold a connection open for that. Chrome kills an idle extension service worker in about thirty seconds, and no heartbeat can run when there's nothing alive to send it. The primitive for this is the opposite of staying awake: let the worker die, and have the browser's push service resurrect it for one job. That's Web Push, and getting it working from a Cloudflare Worker turned out to be the most interesting crypto detour I've taken in a while.

The extension half is almost suspiciously easy

Extensions have been able to use the standard Push API since Chrome 88. You add the notifications permission, and the background service worker subscribes like any web page would:

sub = await sw.registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: urlB64ToBytes(VAPID_PUBLIC_KEY),
});

The extension posts that subscription (an endpoint URL plus two keys) to Repoker's API, tied to the signed-in user. Receiving is a push event listener that shows a notification and stores the click target:

sw.addEventListener("push", (event) => {
  const data = event.data.json();
  event.waitUntil(
    ext.notifications.create(data.url, {
      type: "basic",
      iconUrl: ext.runtime.getURL("icons/icon-128.png"),
      title: `Vote now · ${data.roomName}`,
      message: `Estimating: ${data.title}`,
    }),
  );
});

Clicking it opens the GitHub issue, where the extension's on-page nudge takes over. The service worker was dead the entire time until the push arrived, woke it, and let it die again. No keepalive, no polling. It's the piece of MV3 that finally works with the disposable-worker model instead of against it.

So the client took an afternoon. The server is where the story is.

Nobody hands you Web Push on a Worker

A push endpoint won't accept a plain JSON POST. Two RFCs stand between you and that notification: RFC 8292 (VAPID, a signed JWT proving the push came from your server) and RFC 8291 (the payload must be encrypted, per message, for that one subscription).

The usual answer is the web-push npm package, which leans on Node's crypto and https modules. On a Cloudflare Worker I'd rather own the hundred-odd lines of Web Crypto than fight compatibility shims, and honestly, I wanted to see the machinery. It fits in one file.

VAPID is the friendlier half. Build a tiny JWT claiming the push service's origin as audience, sign it ES256 with a private key only the Worker holds:

const aud = new URL(endpoint).origin;
const exp = Math.floor(Date.now() / 1000) + 12 * 60 * 60;
const payload = b64urlEncode(enc.encode(JSON.stringify({ aud, exp, sub: cfg.subject })));
const sig = await crypto.subtle.sign({ name: "ECDSA", hash: "SHA-256" }, key, enc.encode(`${header}.${payload}`));
return `vapid t=${signingInput}.${b64urlEncode(sig)}, k=${cfg.publicKey}`;

The matching public key ships inside the extension, and the browser binds every subscription to it. Steal a database of subscriptions and they're useless without the Worker's private key.

The encryption half is where you slow down and read carefully. Each message derives fresh keys: an ephemeral ECDH agreement against the subscription's public key, mixed with the subscription's auth secret through two rounds of HKDF, producing a 16-byte content key and a 12-byte nonce:

const keyInfo = concat(enc.encode("WebPush: info\0"), uaPublic, asPublic);
const ikm = await hkdf(authSecret, ecdh, keyInfo, 32);
const cek = await hkdf(salt, ikm, enc.encode("Content-Encoding: aes128gcm\0"), 16);
const nonce = await hkdf(salt, ikm, enc.encode("Content-Encoding: nonce\0"), 12);

Then AES-128-GCM over the payload plus a one-byte delimiter, prefixed with a small header carrying the salt and the ephemeral public key. Every string in those info parameters matters, including the null terminators. Get one byte wrong and nothing tells you which one; the push service just says no, or worse, says 201 and the browser silently drops a message it can't decrypt.

When I grow up, I want to be a watermelon

That failure mode, wrong byte, no error, is why the best part of RFC 8291 is section 5. The spec authors ship a complete worked example: fixed keys, a fixed salt, and the plaintext "When I grow up, I want to be a watermelon", all the way down to the exact bytes of the final encrypted message.

Which means the encryption core is testable in the strictest possible sense. I'd factored mine to accept an injected key and salt precisely so a test could pin it to that vector, and then, I'll admit, shipped without writing the test. The comment claiming testability sat there for a week until writing this post shamed me into it. It passes, byte for byte:

const out = await aes128gcmEncrypt(
  new TextEncoder().encode("When I grow up, I want to be a watermelon"),
  uaPublic, authSecret, asPrivate, asPublic, salt,
);
expect(b64urlEncode(out)).toBe(VECTOR.message);

If you implement this yourself, write that test first. It converts "why is the push service rejecting me" from an evening of guesswork into a failing assertion.

Deciding who gets woken up

The crypto is fussy but bounded. The design question with actual judgment in it is: when a round starts, whose machine buzzes?

Repoker's answer lives in the room's Durable Object. When the facilitator points a ticket, it collects the room's members, subtracts the facilitator, subtracts everyone currently connected (they can already see the round), and sends an encrypted push to whoever remains. Dead subscriptions answer 404 or 410 and get pruned on the spot.

Then there's the rule I'd argue matters more than all the cryptography: one push per room per fifteen minutes. A facilitator flipping through ten tickets in a pointing session is one event, "we're estimating now", not ten notifications. The cooldown is even reserved before sending, so a burst of activity can't race past it. Have you ever kept notifications on for an app that pinged you per item instead of per session? Neither has anyone else, for long. A notification channel is trust you spend; the fastest way to lose it is to be technically correct about every individual event.

There's a toggle in the extension popup to turn the whole thing off, and signing out unsubscribes. That's table stakes, but it's the kind of table stakes that store reviewers now rightly ask you to document.

Where it stands

One honest limitation: this is Chrome-first for now. Firefox runs MV3 backgrounds as event pages rather than service workers, so there's no registration.pushManager there and the subscribe step quietly skips. The rest of the extension works fine in Firefox; the shoulder-tap is a follow-up.

Put together with the last post, the nudge now has two layers. If you're looking at the ticket, the Point in Repoker button lights up and shows who's waiting. If you're looking at nothing at all, your OS taps you: Vote now · Sprint 29. Click, and you're voting.

Both are live in Repoker, on the Chrome Web Store and Firefox Add-ons. And if you're building anything on Workers that needs to reach a browser that isn't looking, the watermelon is waiting for you in section 5.

Why your GitHub App can't see your personal Projects

Matt Fauveau — Thu, 23 Jul 2026 15:50:49 +0000

I was recording a demo video. I had a GitHub project board with a tidy set of tickets on it, Repoker installed and authorized, and a dropdown that was supposed to list my boards. The dropdown was empty.

No error. No red text. Just an empty list where my project should have been, which is the most annoying kind of bug there is. If something had failed loudly I'd have known where to look. Instead I did what you'd do: assumed I'd fumbled a permission somewhere, and went back to the settings page to fix it.

I did not fix it, because there was nothing to fix. What I eventually worked out is that a GitHub App can read organization-owned Projects and cannot read user-owned ones, and no combination of checkboxes changes that. If you've been hunting for the permission that makes your personal Projects visible to your app, I can save you the couple of hours I spent: it isn't there.

The permission that doesn't exist

Here's the part that sends you in circles. Go to your GitHub App's settings and you'll find a Projects permission under Repository permissions. Excellent, you think. That's the one. You set it to read and write, reinstall, and nothing changes.

That checkbox governs the old repository-level project boards, not the ProjectsV2 boards that live at the account or organization level. Same word, different feature. So you keep looking, and you find another Projects permission under Organization permissions, which does control ProjectsV2. Set that one and your org boards work.

Then you go looking for the equivalent under account permissions, for the boards owned by you rather than an org. And you scroll. And it isn't there. There is no account-level Projects permission to grant.

That absence is the whole answer, but it reads like an oversight rather than a rule. I remember toggling things twice and reinstalling the app on my own account just to be sure I hadn't misread the page. Nothing. When a UI lacks the option you're looking for, your first instinct is that you're on the wrong screen, not that the capability doesn't exist.

What the API actually says

The GraphQL API is more direct about it, once you ask in a way that forces an answer.

Listing ProjectsV2 for an account is the same query either way. The only thing that changes is the root field, organization or user, chosen from the account type GitHub reports for each installation:

const owner = type === "Organization" ? "organization" : "user";
const query = `
query($login: String!, $after: String) {
  ${owner}(login: $login) {
    projectsV2(first: 100, after: $after) {
      pageInfo { hasNextPage endCursor }
      nodes { id number title closed }
    }
  }
}`;

Point that at an org and you get your boards. Point the identical query at a user login, authenticated as an App, and GitHub answers:

Resource not accessible by integration

That string is the one people paste into search bars at eleven at night, and it's frustratingly generic. It shows up for all sorts of permission problems, which is exactly why it sends you back to the settings page for another round of checkbox roulette. In this case it doesn't mean "you forgot a permission." It means "this door doesn't open for apps."

Why mine failed silently

So the API does say something. Why was my dropdown just empty?

Because of a line I'd written myself a week or two earlier, for perfectly reasonable-sounding reasons. Repoker lists your projects by fanning out across every account where the app is installed and merging the results:

const lists = await Promise.all(
  installations.map((i) =>
    listProjectsForAccount(token, i.accountLogin, i.accountType).catch(() => []),
  ),
);

Look at that .catch(() => []). The intent was defensive: if one installation out of five has a problem, don't blow up the entire list and show the user nothing. Degrade gracefully. Return what you can.

Which is a good instinct, and it produced the worst possible outcome here. My personal account threw "Resource not accessible by integration," the catch swallowed it, and the fan-out cheerfully returned an empty array for that account. The merge succeeded. The endpoint returned 200. The UI rendered exactly what it was told: nothing.

Graceful degradation and silent failure are the same code path, distinguished only by whether you tell anyone. I'd written the first and shipped the second. The error was there the whole time, caught and dropped a few stack frames from a user who had no way to see it.

Fixing what I could actually fix

I couldn't make GitHub expose personal Projects. That part is closed. What I could fix is the twenty minutes a user would otherwise spend re-reading a permissions page looking for a checkbox that was never printed.

So the empty state stopped being empty. Anywhere Repoker can end up with no projects to show, it now says why, and says what to do instead:

No projects found. Repoker works with organization Projects. GitHub doesn't let apps access personal (user-owned) projects.

That text sits in the lobby when you create a room, in the project picker inside a room, and in the browser extension when it can't read the board attached to an issue. It's in the FAQ on the landing page too, because "can I use this with a personal project?" is a question people will ask before they ever install anything, and the honest answer up front is worth more than a support conversation later.

The extension gets the sharpest version, because that's where you're most likely to hit it mid-flow with a ticket already open:

Repoker can't read this issue's project. GitHub only exposes organization projects to apps, not personal (user-owned) ones. Move the board to an organization and install Repoker there.

Notice what each of those does. It names the constraint, it makes clear the constraint is GitHub's and not something the user misconfigured, and it gives them the one move that actually works. No apology, no vague "something went wrong," no invitation to go check their permissions again.

The workaround, plainly

If you're hitting this yourself, the fix is to move the board under an organization and install the app there. Free organizations exist, and you can create one and transfer a project into it in a few minutes. It feels like overkill for a solo project, and I understand the reluctance, but it's the only path that works today.

For teams it's usually moot, because the board is already org-owned. This bites hardest on exactly the people evaluating your tool for the first time, poking at it with a personal side project before they'd dream of installing it on the company org. Which is a rough audience to fail silently in front of.

What I took away

The platform limitation cost me a couple of hours. The silent failure cost me far more, and it was entirely mine.

I've started treating every catch that returns an empty value as a small decision about who gets to know. Sometimes swallowing really is right, and one flaky installation shouldn't nuke a list. But "the list is empty" and "we couldn't read this account" are different facts, and if you collapse them into the same empty dropdown, you've decided your user doesn't need the difference. They do. They're the one who has to act on it.

If you're building on the GitHub API and your Projects queries are coming back empty, check whether you're pointing at a user or an organization before you touch a single permission. And if you want to see the friendlier version of this failure in the wild, Repoker will tell you exactly what's wrong the first time, which is the least I could do after it told me nothing at all.

Porting a Chrome extension to Firefox without forking the code

Matt Fauveau — Wed, 22 Jul 2026 16:44:02 +0000

I shipped Repoker's extension to the Chrome Web Store first, told myself Firefox could wait, and then a tester asked the obvious question: "Is this coming to Firefox?" So I sat down expecting an afternoon of small annoyances. Porting a Chrome extension to Firefox has a reputation for being fiddly, and the reputation is half-earned. Most of it really is the same code. The other half is a short list of differences that will each cost you an hour if you don't know they're coming.

Both browsers now speak Manifest V3, which is the thing that makes this story short. Firefox landed MV3 support in version 121, so the days of maintaining a separate MV2 build for Firefox are behind us. One manifest version, one set of APIs, mostly one codebase. But "mostly" is doing some work in that sentence, and this post is about the gap.

One codebase, two manifests

The first decision was whether to keep two copies of the extension or build both from one source. Two copies is how you end up with a bug fixed in Chrome and still live in Firefox three weeks later. So the extension is a single codebase, and a tiny build step stamps out the browser-specific bits.

The only real difference between the two manifests is how the background script is declared. Chrome MV3 wants a service worker. Firefox MV3 wants a background scripts array. And Firefox needs one extra block that Chrome doesn't understand. The build script merges a shared manifest.base.json with whichever target you're building:

if (target === "firefox") {
  manifest.background = { scripts: ["background.js"] };
  manifest.browser_specific_settings = {
    gecko: {
      id: "repoker@repoker.app",
      strict_min_version: "121.0",
      data_collection_permissions: { required: ["authenticationInfo"] },
    },
  };
} else {
  manifest.background = { service_worker: "background.js" };
}

That gecko block is worth pausing on. The id is a stable add-on identifier Firefox insists on for a signed extension, and strict_min_version is where the "Firefox got MV3 in 121" fact turns into an actual line of config. The data_collection_permissions field is newer: AMO, Mozilla's add-on store, now asks you to declare up front what data your extension collects. Repoker sends the user's GitHub auth token to its own server to authenticate the session, and it collects no analytics or telemetry, so the honest declaration is a single required permission, authenticationInfo. Everything else in the manifest, the icons, the content scripts, the host permissions, is identical across both browsers.

The `chrome` global that isn't there

Here's the difference that touches the most code, and thankfully it's a one-liner to solve. Chrome and Edge expose the extension APIs on a global called chrome. Firefox exposes the same surface as browser. If your code is littered with chrome.storage.local.get(...), none of it resolves in Firefox.

You could sprinkle if (typeof browser !== "undefined") everywhere. Don't. Alias it once and use the alias everywhere:

export const ext: typeof chrome =
  globalThis.browser ?? chrome;

There's a subtlety that makes this cleaner than it used to be. The old chrome.* APIs were callback-based, and browser.* promisified. That mismatch used to force a polyfill. But every API Repoker touches, storage, runtime, identity, returns a promise on both browsers under MV3, so the alias is genuinely all you need. Import ext, call ext.storage, ext.identity, ext.runtime, and forget which browser you're in.

The redirect that worked everywhere except Firefox

Now the first bug that only Firefox could produce. Sign-in worked perfectly in Chrome, and in Firefox it died with a blunt invalid redirect_uri.

Repoker authenticates the extension with identity.launchWebAuthFlow. The extension asks the browser for its callback URL, sends the user to Repoker to sign in, and the server redirects a freshly minted token back to that callback:

const redirectUri = ext.identity.getRedirectURL();
const url = `${REPOKER_ORIGIN}/api/extension/connect?redirect_uri=${encodeURIComponent(redirectUri)}`;
const finalUrl = await ext.identity.launchWebAuthFlow({ url, interactive: true });

The catch is what getRedirectURL() actually returns, because it differs by browser. On Chromium it hands back https://<id>.chromiumapp.org/. On Firefox it's https://<id>.extensions.allizom.org/. Two different vendor-controlled hosts for the exact same job.

My server, quite reasonably, refused to redirect a token to any host it didn't recognize. You never want to bounce a freshly minted credential to an arbitrary URL, so the endpoint validates the redirect target against an allowlist. The bug was that the allowlist only knew about Chrome:

function isExtensionRedirect(uri) {
  const u = new URL(uri);
  return u.protocol === "https:" &&
    (u.hostname.endsWith(".chromiumapp.org") ||
     u.hostname.endsWith(".extensions.allizom.org"));
}

Adding the Firefox host to the check fixed it. The lesson I took away: any time a browser hands you a magic URL, assume the other browser's magic URL looks different. The security posture stays the same, you're still only ever redirecting to a vendor host you trust, but "the vendor host" is now two hosts.

The bug that wasn't about Firefox at all

The second Firefox-only failure was sneakier, because the fix belonged somewhere else entirely.

With auth working, I opened a room in Firefox and it hung on "Linking this issue to the room." The console showed a Content Security Policy violation: the page had blocked a connection to wss://repoker.app. The socket that carries every vote was refusing to open.

The reason is that a content script runs in the page's world, so it inherits the page's CSP. GitHub ships a strict connect-src, and Firefox enforces it against content scripts where Chrome had been letting it slide. So the very code that worked in Chrome was never actually allowed to work, and only Firefox was strict enough to say so.

The fix was to move the WebSocket out of the content script and into the background, which isn't subject to any page's CSP. That turned out to be the right move for a completely separate reason involving Manifest V3's service worker lifecycle, which I wrote about in making a WebSocket survive Manifest V3. Two different problems, one architecture change that solved both. Have you noticed how often that happens? The constraint you resent ends up pushing you toward the design you should have picked anyway.

Getting through AMO review

One last difference that has nothing to do with code and everything to do with shipping. Mozilla reviews add-on source. Because the extension is bundled with esbuild, the code AMO sees in the package isn't the code I wrote, so the submission has to include the source and instructions to reproduce the build.

That pushed me to make the extension genuinely self-buildable, which is a good discipline regardless. From the source archive, a reviewer runs npm install and one build command and gets back the exact dist/ that was uploaded. The one wrinkle worth flagging: the extension imports a shared types file from outside its own folder, so the source archive has to preserve that relative path or the build won't resolve it. I found that out by extracting the archive into a clean directory and building it myself, which is exactly what a reviewer does, and exactly the check you want to run before you submit rather than after they bounce it.

What the port actually cost

Add it all up and porting a Chrome extension to Firefox came to this: one build flag, a manifest block, a one-line API alias, one allowlist entry, and a socket that moved to where it should have lived from the start. The genuinely Firefox-specific work was an afternoon, most of it the two bugs above. The self-buildable packaging for AMO took longer than the code, and it was worth it.

If you're weighing whether to bother, I'd say do it. A second store listing is real distribution, the shared-codebase tax is close to zero once these differences are handled, and every Firefox user who installs it is someone Chrome was never going to reach. Repoker's extension is live on both the Chrome Web Store and Firefox Add-ons now. Same code, two homes.

Making a WebSocket survive Chrome's Manifest V3

Matt Fauveau — Tue, 21 Jul 2026 18:30:45 +0000

The bug reports all sounded the same. "It disconnected again." No error, no warning, nothing on screen to explain it. Someone would open a GitHub issue, start a planning-poker vote, then stop to actually read the thing they were estimating. Thirty seconds later they'd look back and the room had quietly gone still. Other people's votes weren't showing up, and their own weren't reaching the room. It had simply stopped, without a word.

If you've ever built anything real on Chrome's Manifest V3, you can probably guess where this is going. The socket didn't drop because the network hiccupped. It dropped because Chrome reached over and killed the process it was living in.

This is the story of that bug, and what it actually takes to keep a WebSocket alive inside a Manifest V3 extension.

TL;DR: Manifest V3 runs your background code in a service worker that Chrome terminates after ~30s idle. If your WebSocket lives there, it dies with it, silently. The fix is three parts: a heartbeat so extension activity keeps the worker awake, auto-reconnect that pulls a fresh snapshot so drops are invisible, and a try/catch around every port message because the worker can die between your null-check and the call.

Why the socket doesn't live where you'd expect

First, some context on how the extension is wired, because it explains why this bug was even possible.

It puts a button on GitHub issues and boards. Click it, and a live planning-poker room opens right there in the page. Votes flow over a WebSocket to a Cloudflare Durable Object that owns the room's state. Standard real-time stuff.

The obvious place to open that socket is the content script, the code injected into the GitHub page. That's where the UI lives, so why not open the socket right next to it?

Firefox is why not. A content script runs in the page's world, which means it inherits the page's Content Security Policy. GitHub ships a strict connect-src, and Firefox enforces it against content scripts. Try to open wss://… from there and the browser refuses. (Chrome is more lenient here, but I wanted one codebase, not two.)

So the socket moved to the background. The background service worker isn't subject to any page's CSP, so it can open the WebSocket freely. The content script talks to it over a chrome.runtime port, and the background relays frames both ways. Problem solved.

Except moving the socket into the service worker is exactly what set up the disconnect bug. Which brings us to Manifest V3.

What Manifest V3 took away

If you built extensions in the Manifest V2 days, you had a persistent background page. It loaded when the extension started and stayed loaded. A WebSocket opened there just... stayed open. That was the whole model.

Manifest V3 replaced that background page with a service worker, and service workers are built to be disposable. Chrome spins one up to handle an event, then terminates it once things go quiet, after about 30 seconds of inactivity. The idea is efficiency: don't keep code resident that isn't doing anything.

But a WebSocket is doing something. It's holding a connection open. The trouble is that holding a connection open doesn't, by itself, count as activity. So Chrome looks at your idle service worker, decides it's dead weight, and shuts it down. Your socket goes with it, silently, with no close frame the user ever sees.

That's the disconnect. Not a network problem. A lifecycle problem. The fix has three parts.

Part one: a heartbeat to stay awake

The first job is keeping the service worker alive while a room is open. And the rule that saves you is this: extension activity resets the idle timer. Messaging traffic counts. WebSocket traffic counts.

So the extension sends a heartbeat. Every 20 seconds, the content script posts a small message over the port, the background answers by sending a ping frame on the socket, and that traffic keeps the worker's idle timer from ever reaching zero.

// Keep the port busy roughly twice per MV3 idle window (~30s).
const HEARTBEAT_MS = 20_000;
this.heartbeat = setInterval(() => this.post({ __ping: true }), HEARTBEAT_MS);

Twenty seconds, not twenty-nine, on purpose. The idle window is around 30 seconds, so you want to poke it at least twice per window and leave slack for a slow frame. Cutting it close is how you end up debugging the same disconnect all over again.

Now, you might worry about the cost of pinging a server every 20 seconds for every open room. Here's the nice part. The room lives in a Durable Object that hibernates when nothing's happening, and Cloudflare lets you register an automatic response that answers a ping without ever waking it:

this.ctx.setWebSocketAutoResponse(new WebSocketRequestResponsePair("ping", "pong"));

So the heartbeat keeps the extension's service worker awake, but the server answers each ping with a pong from the runtime itself. The Durable Object stays asleep. You get the keepalive you need without paying to wake the room thousands of times a day.

Part two: reconnect like nothing happened

A heartbeat reduces disconnects. It doesn't eliminate them. Laptops sleep, networks flap, and Chrome will still occasionally win the race and tear the worker down anyway. So the second job is making any drop recover on its own.

When the socket dies, the extension reconnects with exponential backoff: wait a second, try again, and double the wait each time up to a 15-second ceiling.

const delay = this.reconnectDelay;
this.reconnectDelay = Math.min(this.reconnectDelay * 2, 15_000);
this.reconnectTimer = setTimeout(() => this.open(), delay);

The part that makes this feel seamless isn't the backoff, though. It's what happens on the other end. When a client connects to a room, the Durable Object's first move is to send a complete snapshot: the current ticket, every participant, who's voted, the whole state of the table. A reconnect gets the same snapshot a fresh connection does. So the client doesn't have to remember where it was or replay anything. It asks again and gets handed the current truth.

Which means a recovered drop is invisible. The socket blinks out, reconnects a second later, the snapshot repaints the room, and the person who stepped away to read a ticket never knows a thing happened.

Not every drop should retry, of course. If the room was deleted, the server closes with a specific code, and the client treats that as final. And after eight failed attempts in a row it gives up and asks the user to reload, because something like a revoked token will never succeed and looping forever helps nobody. It's tempting to reach for "retry everything" or "retry nothing," but both are wrong. Retry the transient stuff, quit on the terminal stuff.

Part three: the error that only shows up in production

Here's the one that cost me an afternoon.

Once the heartbeat and reconnect were in, everything worked on my machine. Then the console started filling with this:

Uncaught Error: Attempting to use a disconnected port object

The port to the background had gone dead, and I was still trying to post to it. My first instinct was a guard: check that the port exists before using it. I already had that check. It didn't help.

It didn't help because of when Manifest V3 kills the worker. It can happen at any moment, including the microscopic gap between checking that your port is alive and actually calling postMessage on it. You check, the check passes, Chrome kills the worker, you post, it throws. A time-of-check-to-time-of-use race, courtesy of a runtime that can pull the rug whenever it likes.

You can't check your way out of a race like that. You have to catch it.

post(msg) {
  if (!this.port) return;
  try {
    this.port.postMessage(msg);
  } catch {
    this.port = null; // the worker died between the check and the call
  }
}

Every send goes through that. The null check handles the common case, and the try/catch handles the case where the world changed underneath you mid-call. Once every postMessage was wrapped, the errors stopped. I've come to treat it as a rule for MV3: any time you touch a port, assume it might already be gone.

The payoff

Put the three together and the extension holds a live connection through everything a real workday throws at it. Idle stretches, sleeping laptops, flaky wifi, and Chrome's own eagerness to reclaim the service worker. The heartbeat keeps it awake, the reconnect makes drops invisible, and the guards keep a lifecycle race from spamming the console.

None of this is exotic. It's the kind of plumbing that never shows up in a demo and only reveals itself after a socket has been open for a few real hours with real people on it. But that's exactly the gap that matters: the difference between something that works when you're testing it and something that works when your team is leaning on it mid-sprint.

I build Repoker, planning poker for GitHub Projects that writes the agreed estimate straight back to your board. The extension is on the Chrome Web Store and Firefox Add-ons. This post was originally published on the Repoker blog.

We had a person whose job was to say "3, 2, 1"

Matt Fauveau — Mon, 20 Jul 2026 19:05:47 +0000

Here's how we pointed tickets.

Everyone on Zoom. Ticket goes up. Each engineer types their number into the Slack thread but doesn't hit enter. Then you thumbs-up the message above to signal you're ready. Everyone waits. Once the reactions are in, the DoE counts down out loud: "three, two, one, point." And you hit enter.

Read that again. We had built, by hand, out of a video call and an emoji, a synchronized reveal mechanism. That's it. That's what planning poker is. We just implemented it in people.

And it half worked, which is the frustrating part. Someone's finger slips and they post early, so now everybody's seen a 5 before the count. Someone's Slack lags and their number lands two seconds late, which reads as hesitation whether or not it was. Someone joins the call late and asks what we're pointing, and we go around again. The countdown itself takes six seconds but the ritual around it takes ten minutes.

The estimating was never the hard part. Five engineers who know the codebase can size a ticket in ninety seconds (that being said, some engineers will actually look at code, but that's a story for another time). What eats the hour is the choreography.

And then the number goes nowhere. It sits in a Slack thread. The board lives in GitHub. Between them is a person remembering to type it in later, and often that person doesn't. I've seen sprint boards where a third of the tickets had no points, not because nobody estimated them but because the transcription step quietly failed. Two weeks later somebody asks why velocity looks off.

So I built Repoker, which is mostly just the countdown, automated. Pull in a ticket, everyone picks a card, everything flips at once because a machine is doing the flipping, and the agreed estimate writes itself back to GitHub Projects. Nobody says "three, two, one." Nobody thumbs-up anything. Nobody transcribes.

It's entirely Cloudflare underneath: Workers for the app, Durable Objects with per-room SQLite so each session's state stays isolated, D1 for what outlives a session. Real-time voting is close to the canonical Durable Object use case. It's also themed around Casino Royale, just for fun.

I got things wrong along the way. The reconnect logic was the fun one: a WebSocket loop that, under a specific tab-backgrounding condition, fired about eight thousand requests before I noticed.

It's currently free, please try it and give me feedback. If your team still has someone counting down out loud, I'd like to hear how that's going.