It appears to be an error on my end; although it would be better to have an improved error message.

I dug a bit more, and it appears that the OAuth flow cancels the redirect when my server doesn't respond in time. After about 1.6 seconds from clicking Authorize, the redirect to my server appears as "(cancelled)" in the Network tab, and the Authentication Successful page appears.

How to Fix It

To prevent the browser from cancelling the redirect, your callback endpoint needs to be highly optimized and finish its work asynchronously, or respond much faster.

1. Optimize Backend Database and API Requests

Parallelize Requests: If you are fetching a user profile and doing another independent API call, ensure they are running concurrently (e.g., using Promise.all() in Node.js) rather than awaiting them sequentially.

Database Indexing: Ensure your lookups (like finding a user by their provider ID) are properly indexed so the DB query completes in milliseconds.

1. Implement an Immediate "Handshake" Redirect (Defensive Architecture)

If you cannot guarantee your authentication logic will always run under 1.6 seconds, split the process:

The Callback Route: When https://my-url/callback is hit, immediately accept the code parameter, save it to a temporary cache or minimal session state, and instantly redirect the user to a loading page on your site (e.g., https://my-url/auth/loading).

The Loading Page: This page can display a "Logging you in..." spinner. While the spinner is running, your backend can finish processing the slow token exchange and DB operations in the background. Once finished, the frontend can poll or use a WebSocket to route the user to their final dashboard.

This immediately returns a 302 Found status back to the browser, satisfying Railway's strict timeline and preventing the request from appearing as (cancelled).

Thanks ChatGPT.

do you have Serverless enabled on your service?

This is regarding Railway OAuth -- my server is not running on Railway.