OSC_ENVIRONMENT derived from OSC_HOSTNAME breaks reauth on Elastx (prod-se) instances

[birme]

Problem

docker-entrypoint.sh derives OSC_ENVIRONMENT from OSC_HOSTNAME:

if [ -z "$OSC_ENVIRONMENT" ]; then
  OSC_ENVIRONMENT=$(echo "$OSC_HOSTNAME" | sed 's/.*auto\.\(.*\)\.osaas\.io/\1/')
  export OSC_ENVIRONMENT
fi

For any instance hosted on OSC's Elastx cluster, OSC_HOSTNAME is *.auto.prod-se.osaas.io, so this derives OSC_ENVIRONMENT=prod-se. Both api_re_auth.ts and api_share.ts then build the OSC token-service URL as:

https://token.svc.prod-se.osaas.io/servicetoken

prod-se is the name of the hosting cluster, not a platform environment — the actual shared OSC platform hostname for production is (and always has been) token.svc.prod.osaas.io. There is no token.svc.prod-se.osaas.io route on the OSC platform side (fixed as a stopgap in Eyevinn/infra-osaas#112, but that's a platform-side Band-Aid, not a fix for the underlying assumption).

The result: reauth fails with a 500 ("ServiceToken Service failed to generate new SAT Token after 3 attempts") for every Elastx-hosted instance that hasn't been manually patched around this.

History

• Introduced in 520703e (2025-09-01), harmless at the time (single cluster, hostname segment == platform env name).
• Became a live bug once instances started running on Elastx (~2026-06-09).
• Diagnosed in docker-entrypoint.sh: allow OSC_ENVIRONMENT override #247 (2026-06-24) for svt4w-* tenants; instead of a code fix, those three deployments were hand-patched with a custom container command hardcoding OSC_ENVIRONMENT=prod, bypassing the entrypoint's derivation entirely.
• PR chore: bump Fastify, fix OSC_ENVIRONMENT override, remove stray dotenv.config() #254 (merged 2026-09-14) made OSC_ENVIRONMENT overridable if pre-set, but nothing in the OSC deployment pipeline sets that override for new instances — so every instance created without a manual hand-patch is still broken today, including one created 2026-09-15 (reported in Eyevinn/open-intercom-site#225).

Suggested fix

Don't conflate "which cluster hosts this instance" with "which OSC platform environment issues its tokens." Options:

1. Normalize the cluster suffix before building the shared-service URL — e.g. strip a trailing -se (or any future per-cluster suffix) when constructing token.svc.*.osaas.io / the /delegate/* URL specifically, while leaving OSC_ENVIRONMENT itself untouched for other uses.
2. Or introduce a distinct var (e.g. OSC_PLATFORM_ENVIRONMENT) for building shared-service URLs, separate from whatever reflects the instance's own hosting cluster, and have it default correctly instead of relying on hostname parsing.

Either way, the fix needs to work automatically for every new instance with no per-deployment manual override, since that's exactly what has silently broken repeatedly since June.

Affected instances (Elastx, as of 2026-09-15)

All instances under eyevinn-intercom-manager namespace on prod-se except the three hand-patched svt4w-* ones: bjorns-walkietalkie, cabalesprs-intercom, dmcse-intercombeta, dmcse-intercomprod, east-eastcom, etv-intercom, eyevinnlab-intercom, eyevinnlab-jonas, eyevinnlab-test, lucas-openlive, nrk-test, sandviken-myintercom11539, simonwork-myintercom58833, testnp-intercom, testsimon-simon, testsimon-simon2, testsimon-test, yle-yleintercom.

Lessons

None yet — filed as a research/investigation report, no code change proposed here.

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com