For several days, Stensibly's GitHub login was broken in a way that looked almost exactly like a network problem.
The browser could reach Stensibly. Stensibly could redirect to GitHub. GitHub could redirect back. The callback landed in the right Cloudflare Worker. Then the Worker tried to exchange the GitHub authorization code and returned:
network_exception
That left us with a depressingly wide suspect list. GitHub credentials, callback configuration, Cloudflare networking, proxy behavior, DNS, TLS, request options, PKCE, timeouts: all of them were plausible enough to burn time.
None of them was the cause. The request was never leaving the Worker.
The innocent-looking line
The GitHub client supported dependency injection so tests could provide a fake fetch implementation:
this.fetchImpl = options.fetch ?? fetch;
Later it made requests like this:
await this.fetchImpl(url, init);
That looks equivalent to:
await fetch(url, init);
In JavaScript, it is a different call. object.function() passes object as the function's this receiver, so we had taken Cloudflare's native Worker fetch, stored it as a property on our GitHub client, and then invoked it as though it were a method belonging to that client.
Conceptually, production was doing this:
nativeFetch.call(githubClient, url, init);
The evidence strongly indicated that the Worker runtime rejected the incompatible invocation with an Illegal invocation-style TypeError before attempting the outbound request. Raw exception messages were deliberately excluded from the OAuth callback, so that exact internal string was never retained, but the causal evidence became strong: direct Worker calls succeeded, the adapter call failed with a bounded type_error, removing request options changed nothing, and wrapping the native function fixed the next real login.
The repair was small:
const fetchImpl = options.fetch;
this.fetchImpl = fetchImpl
? (input, init) => fetchImpl(input, init)
: (input, init) => globalThis.fetch(input, init);
The application-owned wrapper prevents later method syntax from rebinding the host function. The next fresh login worked.
Why the tests and probes passed
The tests covered the request in considerable detail: URL, headers, form body, PKCE verifier, redirect URI, timeout classification, provider responses, redaction, and one-shot authorization-code exchange. Their fake fetch implementations were arrow functions, though, and arrow functions ignore dynamic this binding. The tests reproduced the request data while silently erasing the runtime behavior that failed in production.
The production probes had a similar blind spot. A temporary Worker probe reached GitHub's token endpoint from both production origins using the configured OAuth credentials, production User-Agent, and the same timeout signal. GitHub returned the expected bad_verification_code response for a deliberately invalid code.
That proved the network path was healthy. It did not prove the production client was invoking that path correctly.
The probe called:
fetch(...)
Production called:
this.fetchImpl(...)
We reproduced the destination, request, credentials, and runtime. We did not reproduce the call expression. That tiny difference was the entire bug.
The investigation got useful when the error got smaller
At first the callback collapsed everything into network_exception, which invited network-shaped theories. The investigation changed once the failure was classified more narrowly.
Timeout failures were separated from other exceptions. Then bounded detail revealed type_error. An operation field showed that the exception occurred during preflight, before the single-use OAuth state was consumed and before the real authorization-code exchange.
The diagnostic payload eventually looked like this:
{
"stage": "token_exchange",
"reason": "network_exception",
"detail": "type_error",
"operation": "preflight",
"colo": "LAX"
}
Two recently added request options, cache: "no-store" and redirect: "manual", briefly became leading suspects. Removing them left the failure unchanged. That negative result forced a line-by-line comparison between the successful probe and the failing client, where the receiver attached by method-call syntax finally stood out.
What was actually wrong
Cloudflare exposed the sharp edge, but the application created it. GitHub was behaving normally, and the same Worker could reach GitHub through direct calls. Production was fixed without changing credentials, callback URLs, DNS, proxies, or provider settings.
The deeper failure was in the abstraction around the host function. We treated a runtime capability as a freely rebindable method, typed the dependency more broadly than the client needed, used mocks that modeled results while erasing native invocation semantics, and built a probe that reached the real destination while bypassing the real adapter.
That combination explains why a one-line defect survived several apparently serious checks. Each check reproduced most of the situation and omitted the one detail that mattered.
There are a few practices worth carrying forward because they fall directly out of the incident. Wrap host APIs before storing or injecting them. Type the callable capability the application actually needs. When a production-only failure appears, make at least one probe execute the production adapter with the same call syntax. And keep diagnostics bounded but specific enough to distinguish local invocation failures from genuine network failures.
The useful lesson here is less glamorous than the debugging story: realism in a test or probe is selective. A check can be impressively faithful to the URL, credentials, environment, and request body while missing the semantics of the expression that makes the call.