Hi Prisma Team! My Prisma Client just crashed. This is the report:
| Name | Version |
|----------|--------------------|
| Node | v14.9.0 |
| OS | debian-openssl-1.1.x|
| Prisma | 2.6.2 |
server/prisma',
enableDebugLogs: false,
enableEngineDebugMode: undefined,
datamodelPath: '/home/akumzy/server/node_modules/.prisma/client/schema.prisma',
prismaPath: undefined,
engineEndpoint: undefined,
generator: {
name: 'client',
provider: '-js',
output: '/home/akumzy/server/node_modules/@prisma/client',
binaryTargets: [],
previewFeatures: [Array],
config: {}
},
showColors: false,
logLevel: 'info',
logQueries: true,
flags: [],
clientVersion: '2.6.2',
enableExperimental: [ 'atomicNumberOperations' ],
useUds: undefined
}
}
plusX Execution permissions of /home/akumzy/server/node_modules/.prisma/client/query-engine-debian-openssl-1.1.x are fine
Prisma Client call: 7m
prisma.queryRaw(SELECT * FROM "User" WHERE "email" ILIKE '%$1%' LIMIT 1, ["[email protected]"])
plusX Execution permissions of /home/akumzy/server/node_modules/.prisma/client/query-engine-debian-openssl-1.1.x are fine
plusX Execution permissions of /home/akumzy/server/node_modules/.prisma/client/query-engine-debian-openssl-1.1.x are fine
Error: PANIC: expected 0 parameters but got 1
This is a non-recoverable error which probably happens when the Prisma Query Engine has a panic.
If you want the Prisma team to look into it, please open the link above 馃檹
at NodeEngine.handleRequestError (/home/akumzy/server/node_modules/@prisma/engine-core/dist/NodeEngine.js:140:1)
at /home/akumzy/server/node_modules/@prisma/engine-core/dist/NodeEngine.js:840:1
at process.result (internal/process/task_queues.js:93:5)
at PrismaClientFetcher.request (/home/akumzy/server/node_modules/@prisma/client/src/runtime/getPrismaClient.ts:1147:15)
at CreateAccount (/home/akumzy/server/src/controllers/clientAuthentications.ts:308:7)
at exports.Manager.execute (/home/akumzy/server/node_modules/@hapi/hapi/lib/toolkit.js:60:28)
at Object.internals.handler (/home/akumzy/server/node_modules/@hapi/hapi/lib/handler.js:46:20)
at exports.execute (/home/akumzy/server/node_modules/@hapi/hapi/lib/handler.js:31:20)
at Request._lifecycle (/home/akumzy/server/node_modules/@hapi/hapi/lib/request.js:370:32)
at Request._execute (/home/akumzy/server/node_modules/@hapi/hapi/lib/request.js:279:9)
plusX Execution permissions of /home/akumzy/server/node_modules/.prisma/client/query-engine-debian-openssl-1.1.x are fine
plusX Execution permissions of /home/akumzy/server/node_modules/.prisma/client/query-engine-debian-openssl-1.1.x are fine
Prisma Client call:
prisma.queryRaw(SELECT * FROM "User" WHERE "email" ILIKE '%$1%' LIMIT 1, ["[email protected]"])
Hello! Can you please provide a minimal reproduction for the above crash? Unfortunately the automatically collected information in the issue does not give us much to go with here - we will need a bit more information. What were you doing? Can you share the code and schema that was active?
Also, regarding the max url suggestion, we are in process of improving the automatic error reports and we will definitely consider your suggestion.
Hi @pantharshit00 I was simply using
prisma.$queryRaw<User[]>('SELECT * FROM "User" WHERE "email" ILIKE '%$1%' LIMIT 1', email)
to query which works perfectly using pg Admin but panic using Prisma.
Hey @Akumzy
Thanks for sharing the query. What is the problem here is '%$1%' is not a postgres string and any postgres variable $1, $2, $3 will not be replaced inside of query.
Since you are passing a variable and prepared statement doesn't expect a variable, it panics and throws the error which prompted you to open this issue.
So in order to perform this query, do something like this:
prisma.$queryRaw<User[]>('SELECT * FROM "User" WHERE "email" ILIKE $1 LIMIT 1', `%${email}%`)
The above query will use postgres replacement and will work.
I will also discuss with the team if we should panic here or we should throw a different error message.
We decided a better error message would indeed be optimal here: https://github.com/prisma/prisma-client-js/issues/883 For now please let us know if using the parameter different, as @pantharshit00 described, solves your problem.
Maybe we can also reflect this in the documentation better.
@janpio it solved the issue. thanks guys.
Most helpful comment
@janpio it solved the issue. thanks guys.