(V3) Prisma fails in staging, while working fine in local | Trigger.dev | Page 1

next kindle Apr 8, 2024, 1:17 PM

#

Hi,

I'm currently working with V3 and I'm using prisma in my task.

When I tested the task run in local ("dev:you"), it worked fine. But when I pushed it to staging and tried to run, I got following error:

prisma:error Invalid `prisma.searchRequest.findUnique()` invocation: Unable to require(`/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node`). Prisma cannot find the required `libssl` system library in your system. Please install openssl and try again. Details: libssl.so.1.1: cannot open shared object file: No such file or directory

I have setup "postinstall": "prisma generate" in my package.json.

Do you happen to know what could be a problem here?

next kindle Apr 8, 2024, 2:05 PM

#

(V3) Prisma fails in staging, while working fine in local

rotund fable Apr 8, 2024, 2:15 PM

#

Aha yes, we need to make it so the CLI automatically detects this and guides you.

You need to add some things to your trigger.config.ts file

#

https://trigger.dev/docs/v3/trigger-config#prisma-and-other-generators

Trigger.dev

The trigger.config.ts file - Trigger.dev

This file is used to configure your project and how it's bundled.

next kindle Apr 8, 2024, 2:33 PM

#

Hi Matt,

Yeah, I have added those already, but still the same error.

rotund fable Apr 8, 2024, 3:10 PM

#

In your prisma.schema have you set the binaryTargets on the generator client? So we can reproduce this

next kindle Apr 8, 2024, 3:12 PM

#

rotund fable In your prisma.schema have you set the `binaryTargets` on the generator client? ...

No, I haven't set it. My prisma.schema looks like this, if that makes any difference.

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["multiSchema"]
}

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DATABASE_DIRECT_URL")
  schemas   = ["auth", "public"]
}

... // Models

rotund fable Apr 8, 2024, 3:15 PM

#

Ok hmm interesting. We're going to add OpenSSL to the image now, it shouldn't take long

next kindle Apr 8, 2024, 3:16 PM

#

rotund fable Ok hmm interesting. We're going to add OpenSSL to the image now, it shouldn't ta...

Thank you

next kindle Apr 9, 2024, 8:10 AM

#

rotund fable Ok hmm interesting. We're going to add OpenSSL to the image now, it shouldn't ta...

Hi Matt,

Sorry for pinging, I was wondering when this would be completed? I have redeployed the staging, but it's still the same.

rotund fable Apr 9, 2024, 8:42 AM

#

No problem, we just published the latest which now includes OpenSSL. We're hoping the GitHub action is fixed too, although we needed to publish to properly test that

next kindle Apr 9, 2024, 9:03 AM

#

Thanks, can confirm that staging now works for me.

Github action didn't work, but this time it was a different error. It might be the problem on my side, i'm not sure.

next kindle Apr 9, 2024, 12:39 PM

#

Hey @rotund fable

I'm encountering a strange behaviour and I'm quite lost in terms what's wrong:

I deploy a set of tasks to staging
I deploy the same set of tasks to development via npx trigger.dev@beta dev
It runs fine is staging, but timeouts in development with prisma timeout error.

Notably, the first few prisma calls in development work just fine, but then it always timeouts. Both staging/development are talking to the same database.

I asked my collegue to deploy to development and it works fine for him. I checked envs between us both, they are the same. I tried to create a new account for myself and deploy from it, but no difference.

Do you happen to know what this might be?

rotund fable Apr 9, 2024, 12:43 PM

#

Just to make sure I understand

It works find when deployed to staging
When running on your local machine (using npx trigger.dev@beta dev) you're getting Prisma timeout errors?

#

Could you share the exact error message? There are different types of Prisma timeouts I think.

next kindle Apr 9, 2024, 12:51 PM

#

yes, exactly.

[31merror[0m - Error while processing search request { searchRequestId: 798, error: { name: 'PrismaClientUnknownRequestError', clientVersion: '5.10.2', message: '\n' + 'Invalid `prisma.candidate.findMany()` invocation in\n' + '/Users/dizotoff/Programming/sourcio/supabase-app/src/server/services/candidatesService.ts:582:59\n' + '\n' + ' 579 criterion: string;\n' + ' 580 }[];\n' + ' 581 }) => {\n' + '→ 582 const candidatesWithAnySkill = await prisma.candidate.findMany(\n' + 'Error occurred during query execution:\n' + 'ConnectorError(ConnectorError { user_facing_error: None, kind: QueryError(PostgresError { code: "57014", message: "canceling statement due to statement timeout", severity: "ERROR", detail: None, column: None, hint: None }), transient: false })', stack: 'PrismaClientUnknownRequestError: \n' + 'Invalid `prisma.candidate.findMany()` invocation in\n' + '/Users/dizotoff/Programming/sourcio/supabase-app/src/server/services/candidatesService.ts:582:59\n' + '\n' + ' 579 criterion: string;\n' + ' 580 }[];\n' + ' 581 }) => {\n' + '→ 582 const candidatesWithAnySkill = await prisma.candidate.findMany(\n' + 'Error occurred during query execution:\n' + 'ConnectorError(ConnectorError { user_facing_error: None, kind: QueryError(PostgresError { code: "57014", message: "canceling statement due to statement timeout", severity: "ERROR", detail: None, column: None, hint: None }), transient: false })\n' + ' at _n.handleRequestError

#

And the strange thing is that there are other prisma calls prior to this one that fails and they work just fine.

rotund fable Apr 9, 2024, 12:55 PM

#

Strange that this is only an issue locally. Does that query return a lot of results?

next kindle Apr 9, 2024, 12:55 PM

#

Yes, this is quite a heavy query. It might take a lot of time to execute as well

rotund fable Apr 9, 2024, 12:56 PM

#

It might be that it's timing out because it's taking a long time to send that data down to your client. Whereas when deploying it's server to server so they have very good internet and are on the internet backbone. Possible even in nearby data centers

#

As a test, if you change it to:

const candidatesWithAnySkill = await prisma.candidate.findMany({
  take: 50,
});

Does that always work?

next kindle Apr 9, 2024, 12:57 PM

#

Yeah, I thought about it. But my collegue was able to run it locally just fine

rotund fable Apr 9, 2024, 12:57 PM

#

They're in the same office with you? I haven't seen this issue with Prisma before tbh.

next kindle Apr 9, 2024, 12:57 PM

#

no, I'm also using vpn

#

right right, I'll check if tweaking that query helps

#

I disabled the VPN and it started to work in local. Thanks a lot Matt!

rotund fable Apr 9, 2024, 1:03 PM

#

No worries 👍

next kindle Apr 9, 2024, 1:07 PM

#

Quick question, when I'm running trigger dev locally, where does the code gets executed? Is it on my machine or it's on your side already?

If it's running on my machine, is it possible to get logs out in the terminal somehow?

rotund fable Apr 9, 2024, 1:10 PM

#

It's on your machine. I think if in your trigger.config.ts file you set logLevel: "info" you will see those

#

Let me know if that doesn't work because we definitely should make that work

next kindle Apr 9, 2024, 1:26 PM

#

I tried to run it with logLevel: "info". No logs visible in terminal, but there are logs visible on your platform website.

rotund fable Apr 9, 2024, 1:49 PM

#

@vague ruin is it possible to get the logs to show locally when running the dev command?

#

I thought you'd shown me that but I might have been imagining it

vague ruin Apr 9, 2024, 2:04 PM

#

Nope they aren't logged in the local terminal at all

#

Just in the platform

#

That logLevel effects which logs get sent to the platform

#

e.g. if you set logLevel to info then debug don't get sent

rotund fable Apr 9, 2024, 2:10 PM

#

@vague ruin I'm guessing the tricky thing with this is that you can have many tasks running at once and all the logs would be mixed up? If we did it, we'd prefix each one with the run_id?

#

It'd be a setting and probably off by default

vague ruin Apr 9, 2024, 2:10 PM

#

Yea exactly, we could do the prefix thing

#

You can use process.stdout.write which will log to the local console

#

(You have you manually add the \n when doing that)

#

That won't go to the platform

next kindle Apr 9, 2024, 2:17 PM

#

Thanks! We are fine with using the provided logger as well, but if those logs could be shown in the terminal at some point, that would be great!

#(V3) Prisma fails in staging, while working fine in local