Connection error only in deployed logs

Hello, I have a website using Next js app router where I get a specific connection error only when it is deployed, not when I run locally. By locally I mean I run the production build and run it locally using npm run start.

I even tried purging the data cache and redeployments but the issue persists

The vercel website is here: Login – Vercel

Basically the behavior is that I have a route handler at /graph which is a GET function. I import that GET function in the page.tsx of the / root endpoint and wrap it in unstable_cache. Somehow it works perfectly fine locally, the console log statements print out as expected. When I deploy on Vercel the /graph endpoint works as expected, but in the vercel log I can see the connection errors for the / root endpoint.

Any help is determining why this connection error happens is greatly appreciated!

The GitHub repo is here:

Hi @mohidm!

Welcome to the Vercel Community :smiley:

Can you share the errors you’re getting? It’d help us debug!

1 Like

Hi @pawlean ,

Thank you! Feel free to recommend additional logging statements I should add that may give useful data.

These are the 3 specific errors I see:

-- Connection error --
Neo4jError: Connection acquisition timed out in 60000 ms. Pool status: Active conn count = 0, Idle conn count = 0.
-- Cause --
undefined
-- Connection error --
Neo4jError: Could not perform discovery. No routing servers available. Known routing table: RoutingTable[database=default database, expirationTime=0, currentTime=1722018975414, routers=[], readers=[], writers=[]]
-- Cause --
Neo4jError: Connection was closed by server
-- Connection error --
Neo4jError: Could not perform discovery. No routing servers available. Known routing table: RoutingTable[database=default database, expirationTime=0, currentTime=1722019966691, routers=[], readers=[], writers=[]]
-- Cause --
Neo4jError: Failed to connect to server. Please ensure that your database is listening on the correct host and port and that you have compatible encryption settings both on Neo4j server and driver. Note that the default encryption setting has changed in Neo4j 4.0. Caused by: Connection lost. Server didn't respond in 60000ms

The library that is used to connect to Neo4j is

Also tried adding await driver.close() to the finally block in neo4j.js in case there was some issue with the driver. I made this change in branch fix-neo4j-conn and it was deployed to Vercel as preview.

Seeing additional errors now (ones highlighted in red) but i don’t think it has to do with me adding the driver.close(), do vercel preview deployments have more verbose logs?

Inside app/page.tsx:

import { read } from '@/lib/neo4j'

export const dynamic = 'force-static'
export const revalidate = 60

export default async function Index() {
  const data = await read()
  return '...'
}

You don’t need to call a separate Route Handler, you can fetch from your database in the server component. Since it looks like you’re wanting to have a static page, and then have an ISR time of 60 seconds, you can do it as follows.

1 Like

Thanks for the reply @leerob , I have done as you suggested and it works fine. I actually put the await read() into a separate function so it can be reused for /graph and / but the idea is this same as you suggested. Also important to note, from my testing the reason your suggestion works is due to removing the unstable_cache.

For testing I tried keeping unstable_cache and using the below settings, and was still able to reproduce the issue.

export const dynamic = 'force-static'
export const revalidate = false

const getCachedGet = unstable_cache(
    async () => await dataGetter(),
    [],
    {revalidate: 60},
);

But as soon as I remove unstable_cache and just use dataGetter() directly and export const revalidate = 60, the issues go away.

In theory using unstable_cache vs just doing revalidate = 60 at the page level should yield the same result right? Could this be a bug with unstable_cache?

You wouldn’t need to use unstable_cache here, because with force-static, you are prerendering the entire route. It is possible there’s a bug with unstable_cache there, yeah, however it should not be used in this use case.

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.