R
Railway14mo ago
MadLex

Random MongoDB Collection Query Issue on Next.js App Deployed via Railway

Hello Railway Community, I am experiencing a peculiar issue with my Next.js application deployed on Railway. My app uses MongoDB with Mongoose to handle database operations. Specifically, during some requests, an unexpected query is being made to the cost_monitoring collection instead of the intended users collection within the getServerSideProps function. Here’s a simplified snippet of my code:
// In my getServerSideProps function
export const getServerSideProps: GetServerSideProps = async (context: GetServerSidePropsContext) => {
const session = await auth(context.req, context.res);
const user = await findUser(session!.user.id);

return {
props: {
user,
},
};
};

// In my database library
export const findUser = async (userId: string): Promise<UserDto | null> => {
await connectMongo();
const user = await UserDb.findById(userId).exec();
// ... rest of the function
};
// In my getServerSideProps function
export const getServerSideProps: GetServerSideProps = async (context: GetServerSidePropsContext) => {
const session = await auth(context.req, context.res);
const user = await findUser(session!.user.id);

return {
props: {
user,
},
};
};

// In my database library
export const findUser = async (userId: string): Promise<UserDto | null> => {
await connectMongo();
const user = await UserDb.findById(userId).exec();
// ... rest of the function
};
The findUser function is expected to query the users collection. However, occasionally, it queries the cost_monitoring collection instead, as seen in my server logs:
getServerSideProps context
Mongoose: cost_monitoring.findOne({ _id: ObjectId("my_user_id") }, {})
getServerSideProps user
getServerSideProps user not found. Redirecting...
getServerSideProps context
Mongoose: cost_monitoring.findOne({ _id: ObjectId("my_user_id") }, {})
getServerSideProps user
getServerSideProps user not found. Redirecting...
The _id value corresponds to a user ID, and I have verified that the cost_monitoring collection isn't referenced anywhere in my code for this operation. The correct behavior, evidenced in other server logs, should be:
getServerSideProps context
Mongoose: users.findOne({ _id: ObjectId("my_user_id") }, {})
user.db: findUser
getServerSideProps context
Mongoose: users.findOne({ _id: ObjectId("my_user_id") }, {})
user.db: findUser
Interestingly, redeploying the same version of the application on Railway seems to resolve the issue temporarily. However, the problem reoccurs randomly at later times with new deployments. Has anyone encountered a similar issue or have any insights on what might be causing this erratic behavior? Thanks in advance. Àlex.
38 Replies
Percy
Percy14mo ago
Project ID: N/A
MadLex
MadLexOP14mo ago
N/A I know it's not directly related to Railway but running locally (npm build && npm start) works fine. In build logs I don't see anything relevant.
Brody
Brody14mo ago
are you using a mongo database hosted on railway or somewhere else?
MadLex
MadLexOP14mo ago
Hosted on MongoDb Atlas but happens either with Railway as well. So I think it must be related to the docker build or something like that
Brody
Brody14mo ago
are you building with nixpacks?
MadLex
MadLexOP14mo ago
Yes, nothing special in my railway.json
{
"$schema": "https://railway.app/railway.schema.json",
"build": {
"builder": "NIXPACKS",
"buildCommand": "pnpm build",
"nixpacksPlan": {
"repo": "my repo"
}
},
"deploy": {
"numReplicas": 1,
"startCommand": "pnpm start",
"sleepApplication": false,
"restartPolicyType": "ALWAYS"
}
}
{
"$schema": "https://railway.app/railway.schema.json",
"build": {
"builder": "NIXPACKS",
"buildCommand": "pnpm build",
"nixpacksPlan": {
"repo": "my repo"
}
},
"deploy": {
"numReplicas": 1,
"startCommand": "pnpm start",
"sleepApplication": false,
"restartPolicyType": "ALWAYS"
}
}
Brody
Brody14mo ago
what version of node are you using locally, and what version is railway using?
MadLex
MadLexOP14mo ago
Local: 18.16.1 Railway: nodejs_18 alright! restarting the deployment fixed the issue as well, not only redeploying. Very weird...
Brody
Brody14mo ago
very odd
MadLex
MadLexOP14mo ago
Update: now it happens every time. That means, once I deploy I have to manually restart the brand new deployment. Again, I cannot reproduce it locally. I will try to use other provider to see if it happens as well. With render and vercel I cannot reproduce it 😔 is it possible to force a restart after a successful deployment? Just as a workaround
Brody
Brody14mo ago
with both those platforms its highly likely they are monkeypatching your code so it just works, railway runs your code as is but yes you can restart, that option is in the 3 dot menu of the deployment
MadLex
MadLexOP14mo ago
Yes I know about that option, just wondering if I can automate it from railway.json or similar. Currently I deploy using the trigger to my branch.
Brody
Brody14mo ago
did you want to restart it on a schedule?
MadLex
MadLexOP14mo ago
Just to restart when a deployment is completed
Brody
Brody14mo ago
you'd be okay with that? I'd highly recommend just fixing the code / config / setup issue
MadLex
MadLexOP14mo ago
I just don’t know how to do it since I can only reproduce it on Railway. I don’t have time to test this maybe in two weeks, but now I have to focus on the launch. Do you know from where to start looking and fix this issue? PS: awesome support btw, much appreciated
Brody
Brody14mo ago
it looks like there's missing data in the database at first start?
MadLex
MadLexOP14mo ago
Hmm, maybe something wrong with the mongoose connection… but I use the one recommended by them. Anyways, will try to reproduce it somehow. Thanks!
Brody
Brody14mo ago
does the happen on every single deployment from github?
MadLex
MadLexOP14mo ago
Yes, every single one
Brody
Brody14mo ago
you said you use mongo altlas right?
MadLex
MadLexOP14mo ago
Yes, that’s right
Brody
Brody14mo ago
are you utilizing the private network for anything?
MadLex
MadLexOP14mo ago
Nope, it’s disabled
Brody
Brody14mo ago
oh well there goes that idea
MadLex
MadLexOP14mo ago
Hmm what do you mean exactly? 😅
Brody
Brody14mo ago
the private network has a total initialisation time of about 2 seconds, during those first two seconds it's very common for any type of external connection to show sporadic issues, even if the connections have nothing to do with the private network, but you have that disabled so that's not the problem in this case
MadLex
MadLexOP14mo ago
Oh I see
Brody
Brody14mo ago
I'm out of ideas for the moment
MadLex
MadLexOP14mo ago
Thanks anyways, will try to add more logs in my connectMongo implementation to see the cycle of the connection status
Brody
Brody14mo ago
sounds good, keep me updated
MadLex
MadLexOP14mo ago
wow, I think I found the issue. This is a screenshot from Trigger.dev, where the job has completed successfully but a task (not awaited) is still running. Very unusual but probably the cause
No description
Brody
Brody14mo ago
interesting
MadLex
MadLexOP14mo ago
I will continue tomorrow, but looks like I can notify Trigger.dev when a deployment is done. There are instructions for Vercel I hope to be able to do it for Railway as well. https://trigger.dev/docs/documentation/guides/deployment-automatic#vercel
Trigger.dev
Automatic endpoint refreshing - Trigger.dev
Use our webhook to automatically tell us when you deploy
Brody
Brody14mo ago
if you can get trigger to only trigger on a specific field value in the json railway sends, absolutely since railway would send a webhook for every event type, and you'd only want to trigger an endpoint refresh on a successful deployment I presume
MadLex
MadLexOP14mo ago
Yes, that’s right. I only need to subscribe to that webhook and refresh trigger.dev endpoint
Brody
Brody14mo ago
right but railway would send multiple webhooks per deployment, for initializing, building, deploying, etc, etc. but you would only want to trigger on a successful deployment
MadLex
MadLexOP14mo ago
Copy that, thanks!
Want results from more Discord servers?
Add your server