`id.kick.com/oauth/authorize` crashes with React error #419 for newer developer apps

[mgladin]

Summary

Loading https://id.kick.com/oauth/authorize with a valid, correctly-formed authorization request (or even a completely fabricated one) crashes the page client-side with Uncaught Error: Minified React error #419 and immediately falls back to a broken redirect to the bare id.kick.com homepage, which then 404s. This happens consistently across multiple browsers, multiple apps, and after waiting an hour between attempts, so it does not appear to be a caching, rate-limiting, or account-session issue.

Environment

• Two independent browsers tested: Safari on MacOS and a separate automated Chromium instance
• Both logged in and logged out states tested
• Tested in a normal window and in Incognito (rules out extensions)

Steps to reproduce

1. Register an app at kick.com/settings/developer with redirect URI http://localhost:8000/api/platforms/kick/oauth/callback and scopes user:read, channel:read, chat:write, events:subscribe.
2. Construct a standard OAuth 2.1 + PKCE authorization URL:

   https://id.kick.com/oauth/authorize?client_id=<CLIENT_ID>&redirect_uri=http%3A%2F%2Flocalhost%3A8000%2Fapi%2Fplatforms%2Fkick%2Foauth%2Fcallback&response_type=code&scope=user%3Aread+channel%3Aread+chat%3Awrite+events%3Asubscribe&code_challenge=<CHALLENGE>&code_challenge_method=S256
   

3. Open that URL in a browser.

Actual result

• Page briefly loads, then crashes with:

  Uncaught Error: Minified React error #419; visit https://react.dev/errors/419 for the full message
  

• Immediately redirects to https://id.kick.com/ (bare homepage)
• That then returns HTTP ERROR 404

Expected result

The Kick login/consent screen should render normally.

What we've already ruled out

• Our request format: Verified byte-for-byte against better-auth's open-source Kick OAuth provider (better-auth/better-auth, packages/core/src/social-providers/kick.ts) — identical authorize endpoint, token endpoint, PKCE flow, and user-info call. Nothing non-standard about our request.
• Hostname: Confirmed using id.kick.com, not kick.com.
• PKCE/state parameters: Crash reproduces identically whether code_challenge/code_challenge_method/state are present, absent, or fabricated.
• client_id validity: Crash reproduces with a completely fabricated, non-existent client_id, and also with two different real, freshly-created apps under our account.
• Scopes: Crash reproduces with the full scope set and with a minimal single-scope (user:read) request.
• Rate limiting: Crash persists after waiting a full hour without any requests to the endpoint.
• App registration state: Reproduces on a brand-new app created from scratch, not just an edited/older one.
• Browser/extensions: Reproduces in Incognito mode with no extensions, and in a second, independent browser environment.

Notable detail

On one attempt, the network tab showed a 429 Too Many Requests response alongside the same React #419 crash, suggesting the app's error handling for a failed background fetch during hydration is what's actually broken — rather than the authorize flow itself. This may point to the root cause: a Partial Prerendering hydration boundary (we observed x-nextjs-postponed: 1 in response headers) is not handling a failed data fetch gracefully, and throwing an unhandled error instead of a graceful fallback/retry.

Why this matters

We can authenticate successfully with Kick through third-party tools (Streamer.bot, Casterlabs) from the same machine/account, so this is not a broad, permanent Kick outage — it appears specific to certain apps/circumstances we haven't been able to fully isolate from outside your systems. Happy to provide our exact client_ids (redacted here) and timestamps of failed attempts if that helps trace it server-side.

Related prior reports

• OAuth authorize endpoint returns 307 → 404 on desktop browser (not mobile) #353 (closed, no root cause identified) reported the exact same symptom — id.kick.com/oauth/authorize → redirect to bare id.kick.com → 404, on desktop browsers, with valid PKCE — and was closed with "working fine on my end" without further investigation. We'd appreciate this one being reopened/revisited given we're hitting the identical failure with much more exhaustive isolation testing (see above).
• Your own docs (getting-started/generating-tokens-oauth2-flow) document a known Next.js middleware bug on this same id.kick.com/oauth/authorize page (the "127.0.0.1 workaround" for query-parameter mangling). That confirms this endpoint has had framework-level query-parsing issues before, which is consistent with what we're observing (a React hydration crash, x-nextjs-postponed: 1 response header) even though the specific 127.0.0.1↔localhost substitution documented there isn't what we're hitting (we already use localhost, not 127.0.0.1).