Skip to content

OG cards key on a 7-char SHA while permalinks key on the full SHA — the first unfurl never reuses the warm slot #147

Description

@lukaso-bot

Found by the review round on #144.

The OG image URL for a commit permalink is always built with a 7-character SHA:
ogImageUrl()commitImageUrl(..., shortSha(result.canonicalSha), ...)
(packages/web/src/ui/og-meta.tsx:65; shortSha is sha.slice(0, 7) at :115).
So web-og calls /internal/result/:owner/:repo/<7 chars> and that endpoint computes
the cache key part sha:<7 chars>.

The public permalink route keys on the SHA as it appears in the request URL, and
/lookup deliberately redirects to the full SHA (packages/web/src/index.ts:138
"Use the FULL SHA in the permalink (not a 7-char prefix)").

Concrete flow, which is the primary search → view → share path:

  1. A user searches honojs/hono@<40-char sha>.
  2. They land on /r/honojs/hono/c/<40>, which warms cacheKey('res', repo, 'sha:<40>', 'cull', 'nopre').
  3. They share that URL. The unfurl fetches the OG image, which resolves sha:<7>
    a different slot. Still cold, still a full lookup.

#144 fixed the write-back half (the OG path now self-heals into sha:<7>, so it is cold
at most once) and made /internal use the public routes' key shape and policy. This is the
remaining half: the two sides spell the same commit two different ways, so a warm public
entry is never reused for the first unfurl.

Why it is not folded into #144

The fix lives in files #144 does not touch (ui/og-meta.tsx, routes/result.tsx), and
either direction changes the public routes' key namespace, which is a cache-invalidation
event for every existing entry and deserves its own review surface:

  • Normalise to short on both sides — possible pre-lookup (sha.slice(0, 7)), but changes
    the public routes' cache key.
  • Normalise to full on both sides — not possible pre-lookup for a 7-char input: you do not
    know canonicalSha until the lookup has run. Would need a second keyed write after resolve.

Short-on-both is the smaller change. Needs a test that seeds the slot a full-SHA permalink
writes and asserts the OG path reads that entry.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions