Prisma1: Prisma client is randomly closing subscriptions due to timeout

Created on 29 Jan 2019  路  4Comments  路  Source: prisma/prisma1

Some users are reporting that prisma client is randomly disconnecting from the prisma server. This happens because we have an inActivityTimout of 60000 ms that disconnects the client. While this is beneficial to avoid memory leaks if the user is not using subscriptions, but this is also leading disconnects.

So we should expose these options in the prisma client configuration object.

bu2-confirmed areclient

Most helpful comment

I have a simple listener process running on pm2. Something like this:

(async function listenForNewPosts() {
    try {
        const postEvent = await prisma.$subscribe
            .post({
                mutation_in: ['CREATED'],
            })
            .node()

        for await (const post of postEvent) {
            console.log(post)
                }
            }
        }
    } catch (error) {
        throw new Error(error)
    }
})()

In this case events may only fire every hour. Using the Prisma client out of the box the client would disconnect and not attempt to reconnect. I was able to remedy the issue by adding the following options to SubscriptionClient

 timeout: 30000,
 inactivityTimeout: 0,
 reconnect: true,

Can see the concern for memory leaks. In this case I'm working around that by setting max_memory_restart within pm2.

All 4 comments

The implementation of inactivityTimeout in subscription-transport-ws considers active number of subscriptions and if there are any active subscriptions the inactivity timeout does not close the connection.

This might be a bug in subscription-transport-ws implementation.

This could also be an issue with construction/usage of subscription client in Prisma client.

This could also be an issue in usage of the Prisma client (code or environment)

To move this forward:-

  1. We can validate the subscription-transport-ws implementation of inactivityTimeout for correctness.
  2. Validate the Prisma client usage of SubscriptionClient, we can wrap the request method on SubscriptionClient and create a new client if the status is closed.
  3. Find a reproduction with current codebase.

Related issues:

Early websocket closure resulting in websocket connections not being instantiated https://github.com/apollographql/subscriptions-transport-ws/issues/377

WebSocket connection closing occasionally https://github.com/apollographql/subscriptions-transport-ws/issues/381

I don't have a reliable repro right now. Maybe someone that has this problem can provide one.

cc @joshhopkins Can you provide a reproduction here?

I have a simple listener process running on pm2. Something like this:

(async function listenForNewPosts() {
    try {
        const postEvent = await prisma.$subscribe
            .post({
                mutation_in: ['CREATED'],
            })
            .node()

        for await (const post of postEvent) {
            console.log(post)
                }
            }
        }
    } catch (error) {
        throw new Error(error)
    }
})()

In this case events may only fire every hour. Using the Prisma client out of the box the client would disconnect and not attempt to reconnect. I was able to remedy the issue by adding the following options to SubscriptionClient

 timeout: 30000,
 inactivityTimeout: 0,
 reconnect: true,

Can see the concern for memory leaks. In this case I'm working around that by setting max_memory_restart within pm2.

This is fixed the the latest alpha, 1.31.0-alpha.3, please install it via npm install -g prisma@alpha

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ragnorc picture ragnorc  路  3Comments

nikolasburk picture nikolasburk  路  3Comments

MitkoTschimev picture MitkoTschimev  路  3Comments

schickling picture schickling  路  3Comments

AlessandroAnnini picture AlessandroAnnini  路  3Comments