Netlify Function Prisma Client claiming "Unknown field" when deployed, development/local works

I’ve written a netlify function to read data from a Railway.app database. It works fine on my local machine (served with netlify dev) but fails once deployed:

https://whereyouat2.netlify.app/.netlify/functions/api?type=games&franchise=uncharted&section=uncharted+2%3A+among+thieves&resource=subsection

The error I’m getting is “Unknown field order_by for select statement on model section.”, it also fails when I try to use orderBy: { order_by: 'asc' }, I’ve renamed that field from “order” to “order_by” in case it was reserved.

I’ve set the “AWS_LAMBDA_JS_RUNTIME” environment var to “nodejs18.x” to match my local environment, that’s not helped.

If I run the function at localhost:8888, I have no issues, my “schema.prisma” has the field in it, and I can see the field in the Railway.app web UI and when I use Heidisql to browse the DB:

model subsection {
  id          BigInt  @id @unique(map: "id") @default(autoincrement()) @db.UnsignedBigInt
  name        String  @db.Text
  description String? @db.Text
  order_by    Int     @default(0) @db.Int
  section_id  BigInt  @default(0) @db.UnsignedBigInt
  section     section @relation(fields: [section_id], references: [id], map: "fk_subsection_section")

  @@index([section_id], map: "fk_subsection_section")
}

Any help would be appriciated, everything else is working fine, just selecting and ordering by “order” or “order_by” fields throw an error

Hey @PeteWilliamson,

I’m not sure how this is a Netlify question. The error seems to be coming from your Railway.app instance, right? Because this doesn’t seem to be an error thrown by Netlify.

Yes, you mention this is not happening locally, but we have no means to debug your database side of this equation. We would probably only be able to confirm you can see this error, but not offer any meaningful advice on how to solve it.

Well the error’s coming from Prismaclient, which is running in the Netlify function. The same code works elsewhere, and the Railway.app instance is a Mysql database, so I don’t see how it can be throwing the error.

I suppose I should download the current deploy and compare the node_modules folder to see if there’s any differencces between my local copy and what’s deployed.

Hi @PeteWilliamson :wave:t6: , yes please do that and let us know your findings.

This makes so little sense to me, I’ve moved the order_by logic into the app, and stopped specifying exact fields so Prismaclient returns everything. Again, locally everything works fine, this is some JSON back from my function locally:

{
id: "4",
franchise_id: "1",
name: "Uncharted 2: Among Thieves",
slug: null,
description: null,
order_by: 2,
subsection_name: "Chapter",

The same code, deployed on Netlify, accessing the same Railway.app endpoint, seems to ignore the order_by field, like it doesn’t exist

{
id: "4",
franchise_id: "1",
name: "Uncharted 2: Among Thieves",
slug: null,
description: null,
subsection_name: "Chapter",

I’ll try rebuilding the code directly into lambda but Prisamaclient is 30Mb so live code editing doesn’t work in AWS.

I’m wondering if the Prisma schema is cached, no changes I seem to make to the schema take effect. The node code changes but I feel like the handler function can’t see changes tot he Prisma schema.

This post suggests things outside the the handler only run once, which might include reading the prisma schema?

Ok I’ve solved it, I had to “Clear cache and deploy site”, so I need to do that after making changes to the Prisma.schema. I suppose it’s effectively dropping all the node_modules and doing an npm install under the hood, that kind of thing?

Hey @PeteWilliamson,

The post you’re referencing to might have some mis-information (rather an incorrect quote). There’s an important detail that has been missed.

The code outside the handler function does persist but only for a short period of time. Since Lambda functions are kind of small-containers that are booted, they run your code and are shut down after the execution, you can get some time of the previous container if you continuously keep hitting the endpoint, thus keeping it “warm”. I personally won’t call this “cache”.

In the simplest words, yes.

1 Like