prisma: Query engine exited with code 101, in Azure Functions
Bug description
Overnight Prisma stopped working inside our environment, with stack trace
{ body: '"PrismaClientInitializationError: \\nInvalid `this.client().setup.findFirst()` invocation in\\nC:\\\\home\\\\site\\\\wwwroot\\\\src\\\\handlers\\\\setup\\\\getOrderTermsAndConditions.js:58:36\\n\\n 55 return prisma_1.getPrisma;\\n 56 }\\n 57 static async get() {\\n→ 58 return this.client().setup.findFirst(\\nQuery engine exited with code 101\\n\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\nthread \'main\' panicked at query-engine\\\\query-engine\\\\src\\\\opt.rs:246:53:\\nCould not open datamodel file \\"C:\\\\\\\\home\\\\\\\\site\\\\\\\\wwwroot\\\\\\\\node_modules\\\\\\\\.prisma\\\\\\\\client\\\\\\\\schema.prisma\\"\\nstack backtrace:\\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\\n at Mg.handleRequestError (C:\\\\home\\\\site\\\\wwwroot\\\\node_modules\\\\@prisma\\\\client\\\\runtime\\\\binary.js:184:7096)\\n at Mg.handleAndLogRequestError (C:\\\\home\\\\site\\\\wwwroot\\\\node_modules\\\\@prisma\\\\client\\\\runtime\\\\binary.js:184:6207)\\n at Mg.request (C:\\\\home\\\\site\\\\wwwroot\\\\node_modules\\\\@prisma\\\\client\\\\runtime\\\\binary.js:184:5927)\\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\\n at async a (C:\\\\home\\\\site\\\\wwwroot\\\\node_modules\\\\@prisma\\\\client\\\\runtime\\\\binary.js:189:9983)\\n at async baseHandler (C:\\\\home\\\\site\\\\wwwroot\\\\src\\\\handlers\\\\setup\\\\getOrderTermsAndConditions.js:14:19)\\n at async AzureMiddleware.run (C:\\\\home\\\\site\\\\wwwroot\\\\src\\\\handlers\\\\setup\\\\getOrderTermsAndConditions.js:735:35)\\n at async Object.handler (C:\\\\home\\\\site\\\\wwwroot\\\\src\\\\handlers\\\\setup\\\\getOrderTermsAndConditions.js:772:13)"', type: 'GET', endpoint: 'https://xxx.azurewebsites.net/api/getOrderTermsAndConditions', requestId: '9f3f40eb-1e0b-4aa6-944e-67a90cb60ed0', referer: 'unknown', status: 'ERROR', userId: 'unknown' }
How to reproduce
Not clear, no code changes happend overnight
Expected behavior
No response
Prisma information
…
Environment & setup
- OS: Windows (Azure Functions)
- Database: Azure SQL Server
- Node.js version: 18.14.1
Prisma Version
5.10.2
About this issue
- Original URL
- State: open
- Created 4 months ago
- Comments: 16 (4 by maintainers)
We have been experiencing issues in our staging environment again. While the issue seemed to have been resolved in our production environment, it has unfortunately resurfaced in staging.
Despite our efforts to understand the root cause of this problem, we have not received any explanation or assistance from Azure. Initially, we believed that the issue might be related to a migration that was being conducted by Azure, but we have since confirmed that no migrations are currently taking place.
As a result of this persistent issue, we are now seriously considering migrating to a different ORM if the problem manifests itself in our production environment again. I hope someone in this thread will have better experience with Azure support in resolving this matter.
Yea we’ve been working with Azure support for over a month now and have made no progress unfortunately.
Did some more investigating and looks like linux function apps do support “deploy from package” now. We were able to move over to Linux with this deploy method and got things working. Azure is still investigating why Windows is having issues, but this is a good work around for now.
We encountered the same issue in our Functions. We have now migrated our Functions from Windows to Linux, and it is working now. Although it sometimes worked on Windows, we have doubts whether we might encounter this issue again in the future with Linux. But for now, we have a functioning application.
I had contact with Azure support, they seem to think it was related to maintenance.
No clear answer yet one what the maintenance touched exactly, and why this broke all of the sudden. Seemed to only break prisma in our codebase, no other dependencies gave errors.
Hi, it’s very difficult because we are not sure what is causing this issues, 90% API calls using Azure Functions are going okay. But in the rare occasion we are seeing this error. As if we do not have access to the Windows file system anymore