Preview OG Worker renders the neutral card for every input — og-preview can't reach web-preview /internal (likely INTERNAL_SECRET unset on preview)

[lukaso-bot]

Found while exercising the #144 preview deploy before calling it mergeable.

The preview OG Worker renders the neutral "no result" card for every input, so the one
surface OG changes actually get reviewed on cannot validate an OG change at all.

Evidence (all read-only GETs, this cycle)

request	preview	production
/r/honojs/hono/c/f82aba8…d176.png (real result)	200, 14348 B, 827 ms	200, 28899 B, 496 ms
/r/honojs/hono/c/0123…6789.png (nonsense SHA, no result possible)	200, 14244 B, 598 ms	—
/i/honojs/hono/11.png (real issue result)	200, 12915 B, 509 ms	200, 35266 B, 577 ms
/placeholder.png (the static file, for reference)	200, 11757 B	200, 11757 B

A real result and a nonsense SHA render cards within 100 bytes of each other, both in under
a second. That is the neutral card in both cases — not the static placeholder.png, and not a
lookup that ran and failed: no lookup is being attempted. Meanwhile the preview web Worker is
healthy and does do real lookups (/r/honojs/hono/c/f82aba8…d176 took 11.9 s and returned a full
27 KB page), so the break is specifically og-preview → web-preview /internal/*.

Most likely cause

INTERNAL_SECRET is not set (or does not match) on the preview Workers. preview.yml documents
it as a manual, per-environment step that the deploy does not perform:

# wrangler secret put INTERNAL_SECRET --env preview   (packages/web AND web-og, same value)

and isServiceBinding() (packages/web/src/routes/internal.ts) fails closed when the secret
is unset — a deliberate, correct choice (#141's fail-closed fix) that here produces a silent 404
on every /internal call, which web-og turns into the neutral card. I have not verified this
directly, because reading or setting a secret is outside what the loop does.

Fix (human, one time — the loop can't do this)

Run both, from the repo root. The same value must go to both Workers, and it must match what
web uses, or the handshake fails exactly as it does now:

cd packages/web    && npx wrangler secret put INTERNAL_SECRET --env preview
cd ../web-og       && npx wrangler secret put INTERNAL_SECRET --env preview

Then re-run the preview deploy on any open PR and re-check: a real commit should render ~29 KB,
a nonsense SHA ~14 KB. Order matters only in that both must be set before the next deploy is
exercised — setting one alone leaves the handshake broken in the same way.

Why it is worth fixing rather than living with

Preview is where OG changes get reviewed, and the last three OG issues (#53, #143, #141) were all
"the unfurl silently served the wrong card". A preview that always serves the wrong card cannot
catch any of them — and worse, it looks like it is working: HTTP 200, a valid PNG, no error
anywhere. Consider also having preview.yml fail loudly if /internal returns 404 to og-preview,
so this can't silently regress again.

[lukaso-bot]

Fresh measurement confirming this is still live, from the preview deploy of PR #158 (2026-08-27):

GET https://released-web-og-preview.lukaso.workers.dev/r/honojs/hono/c/f82aba8.png
status 200 · cache-control: public, no-transform, max-age=60 · 14348 bytes · x-og-template: og.v1

Production serves that same URL at 28899 B with max-age=86400 (liveness probe, same cycle). So the preview is returning the neutral placeholder for a commit that resolves fine in prod — fetchResult is getting null from the Service Binding, consistent with INTERNAL_SECRET being unset on the preview env.

Concrete cost, today: PR #158 changes the OG card's cache-control policy, and the preview cannot validate it at all — a null result is short-cached both before and after that change, so every preview response reads max-age=60 regardless. There is no input that distinguishes the two behaviours on preview. That is the second OG fix in a row reviewed with no working preview.

One more constraint worth writing down here: the OG preview target is shared across PRs (released-og:shared), not isolated like released-web. So even with the secret fixed, the OG preview serves whichever branch deployed most recently — two concurrent OG PRs would each be validating the other's build. Worth deciding alongside the secret.

The 14348 B / 28899 B split is also a usable assertion: a preview health check could fail on the placeholder byte range instead of relying on a human noticing the card looks generic.

[lukaso-bot]

Still live — re-confirmed 2026-08-29 against the og-preview deploy on PR #158.

Two inputs that production distinguishes, hit on preview:

input	preview	production
/r/honojs/hono/c/f82aba8.png (released, → v4.12.11)	200, image/png, 14348B, max-age=60	200, 28899B, real-result card
/r/lukaso/released/c/000…000.png (nonexistent SHA)	200, 15001B, max-age=60	—

Preview gives the same short-cached neutral treatment to a commit it should resolve and to a SHA that does not exist, and the byte size is roughly half production's real-result render. That is the neutral card for every input, i.e. exactly this issue: og-preview cannot reach web-preview's /internal, so fetchResult() returns null and renderImage() falls through to PlaceholderCard.

Consequence beyond the cosmetic one: the per-PR preview is unusable as evidence for any OG-rendering change, because every OG PR's preview renders the placeholder whether the change works or not. #158 is the current case — a green preview there proves the Worker boots, nothing more.

Fix is a human action, not a code change: wrangler secret put INTERNAL_SECRET on both released-web-preview and released-web-og-preview, with the same value on both (the Service Binding handshake compares them — see CLAUDE.md "Secrets / deploy"). Run it once, at any time; it takes effect on the next preview deploy, so re-push or re-run the preview build afterwards to see it. No merge is required first, and it does not touch production's secrets.