Three small items the sona#412 review rounds surfaced and deliberately deferred. None is urgent and none blocks anything; batched here so they stop living only in a chat transcript.
1. A misconfigured fork re-fetches the owner profile daily, forever
When a fork has UploadThing selected as its storage provider but no token, healOwnerAvatar runs every day: the Bluesky profile lookup succeeds, the re-host fails, the heal correctly refuses to write a second hotlink, and nothing converges. The daily lookup is cheap, but it never stops and nothing tells the operator why. A backoff, or a heartbeat note that names the storage misconfiguration, would end the loop or at least explain it.
Observed live during the #412 build-verifier drive ([avatar] rehost error: … UploadThing selected but UPLOADTHING_TOKEN is not configured).
2. The heal's heartbeat has no reader
refresh-avatars writes a job note like refreshed 3/25, 12 remaining, owner avatar now self-hosted, but the job is not in KNOWN_JOBS (src/lib/server/observability.ts, deliberately at the time), and even for listed jobs the panel never renders the detail field. So the one operator-facing signal the heal produces reaches nobody except through the workflow's Actions log.
Fixing it means two decisions, which is why it was deferred: add refresh-avatars to KNOWN_JOBS, and render job.detail in the panel row. The second puts untranslated English cron strings (all five jobs write them) inside an otherwise localized panel, so it drags in an i18n question.
3. One cron run, two definitions of "our origin"
healOwnerAvatar derives its trust anchor from settings.siteUrl, falling back to the request origin, on the principle that a machine endpoint should not take its canonical identity from a caller-supplied Host header. refreshArtistAvatars, called in the same handler, still uses raw url.origin. On a no-CDN fork reached over its *.pages.dev host, artist avatars absolutize against the preview origin while the owner's uses the canonical one.
Fix is to resolve the origin once in the cron handler and pass the same value to both calls. Deferred from #412 because it changes artist-path behaviour on no-CDN forks, which was outside that change's blast radius. Raised independently by two review gates.
Three small items the sona#412 review rounds surfaced and deliberately deferred. None is urgent and none blocks anything; batched here so they stop living only in a chat transcript.
1. A misconfigured fork re-fetches the owner profile daily, forever
When a fork has UploadThing selected as its storage provider but no token,
healOwnerAvatarruns every day: the Bluesky profile lookup succeeds, the re-host fails, the heal correctly refuses to write a second hotlink, and nothing converges. The daily lookup is cheap, but it never stops and nothing tells the operator why. A backoff, or a heartbeat note that names the storage misconfiguration, would end the loop or at least explain it.Observed live during the #412 build-verifier drive (
[avatar] rehost error: … UploadThing selected but UPLOADTHING_TOKEN is not configured).2. The heal's heartbeat has no reader
refresh-avatarswrites a job note likerefreshed 3/25, 12 remaining, owner avatar now self-hosted, but the job is not inKNOWN_JOBS(src/lib/server/observability.ts, deliberately at the time), and even for listed jobs the panel never renders thedetailfield. So the one operator-facing signal the heal produces reaches nobody except through the workflow's Actions log.Fixing it means two decisions, which is why it was deferred: add
refresh-avatarstoKNOWN_JOBS, and renderjob.detailin the panel row. The second puts untranslated English cron strings (all five jobs write them) inside an otherwise localized panel, so it drags in an i18n question.3. One cron run, two definitions of "our origin"
healOwnerAvatarderives its trust anchor fromsettings.siteUrl, falling back to the request origin, on the principle that a machine endpoint should not take its canonical identity from a caller-supplied Host header.refreshArtistAvatars, called in the same handler, still uses rawurl.origin. On a no-CDN fork reached over its*.pages.devhost, artist avatars absolutize against the preview origin while the owner's uses the canonical one.Fix is to resolve the origin once in the cron handler and pass the same value to both calls. Deferred from #412 because it changes artist-path behaviour on no-CDN forks, which was outside that change's blast radius. Raised independently by two review gates.