HydraIssues

hydrabody fetchHeadsForVenue spams HTTP 401 every 30s
closed bug Project: hydrabody Reporter: Cederik (auto, follow-up to #138) 8 May 2026 09:00

Description

hydrabody/pkg/provider/sunshine.go:260 fetchHeadsForVenue calls GET {HeadServiceURL}/api/v1/heads without setting an Authorization header. hydrahead returns 401, hydrabody logs [sunshine] failed to fetch heads: HTTP 401: {error: unauthorized}, and the loop repeats every 30s.

Observed on boom-pickle-38: ~21k log lines of this message, drowning the actual signal. Discovered while debugging #138 — the 401 spam was the loudest thing in the log but is not what caused the user-visible failure (the second registration path via state.Installed still works).

Behavior today: app registration still succeeds via the state.Installed fallback further down tickSunshineApps, so streams keep working. But:

  • log volume buries real errors (had to grep -v just to see anything else),
  • if the state.Installed path ever regresses, this silent auth gap will mask the breakage,
  • it implies head-driven registration (the StreamAppID flow) has been entirely non-functional on this fleet for some unknown amount of time.

Fix: add the bearer token to the request, mirroring fetchLiveExperiences in experiences.go:88 which does set Authorization: Bearer + p.Config.ExperienceLibraryToken. The equivalent token for HeadServiceURL needs to be in BodyConfig (HeadServiceToken or similar) and threaded through; check whether hydracluster already delivers one. Also: throttle / dedupe the error log so a persistent failure doesn't write the same line every 30s.