We're seeing an intermittent OAuth token fetch failure that only occurs on

Railway builds/deploys, never locally, using identical code and credentials.

ERROR (on container startup, repeats every ~5-10 min while present):

Error: Invalid response body while trying to fetch https://oauth2.googleapis.com/token: Premature close

WHAT WE'VE RULED OUT:

• Not a credentials issue: an identical OAuth token fetch (same client

  library, same credentials file) succeeds 3/3 times when run locally on

  the same machine, back-to-back.

• Not a code regression: we diffed the failing commit against a known-good

  commit that ran cleanly for 5+ days — the only changes were to unrelated

  application files (resume parsing/rendering logic), none touching

  networking or auth code.

• Not a dependency version issue: package.json and package-lock.json are

  byte-identical between the known-good and failing commits.

• Not the Google Cloud OAuth config: verified Publishing status is "In

  production," User type "External," and the OAuth Client ID matches our

  credentials file exactly.

• Not a sustained outage: the same known-good commit succeeded cleanly for

  ~8 hours after a rollback, then a separately-deployed commit failed again

  that night.

PATTERN:

Failures appear to correlate with fresh container starts specifically

(restart, redeploy, rollback) rather than a persistent state — the same

known-good commit ran cleanly for ~8 hours after one rollback, but a

separate fresh branch containing only a one-line doc change on top of

that same known-good base failed immediately on its first deploy. Since

the only code difference between that branch and the known-good state is

a single comment line unrelated to networking or auth, this points to an

intermittent issue in the outbound network path from our container to

oauth2.googleapis.com during the OAuth token exchange at startup, rather

than anything in our application.

ADDITIONAL CONTEXT:

This service's GitHub repo was recently renamed (nb-resume-formatter →

hireform). Shortly after, the service's Settings > Source panel began

showing a "GitHub Repo not found" error even though the deploy connection

was still functioning (confirmed via a test commit that deployed

successfully despite the error). We resolved the visible error via

disconnect/reconnect, but wanted to flag this in case there's related

stale internal state affecting this service.

Happy to share full deploy logs for any of the failing attempts, or the

exact commit hashes involved, if useful.