Prisma edge client can't read env vars from .env file

[kelbyfaessler]

Bug description

When I import "@prisma/client" it reads my env vars (e.g. DATABASE_URL).

Using the same .env file, when I import "@prisma/client/edge" it can't read them anymore and I get
InvalidDatasourceError: Datasource "db" references an environment variable "DATABASE_URL" that is not set

This is the local dev server for a sveltekit app, so not even trying to deploy it yet.

The schema code that reads env looks like this:

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
  // directUrl = env("DIRECT_URL")
  relationMode = "prisma"
}

How to reproduce

Create sveltekit skeleton project
Verify it works
Add prisma, a schema (reads DATABASE_URL from env) with a table, and a row of data (mysql planetscale db)
Add a .env file with the database url string
Verify you can query the database and run the local dev server, see the data in the page
Change to the prisma edge client
You'll see the error above

Expected behavior

No response

Prisma information

Relevant parts of schema already provided

Environment & setup

• OS: Fedora
• Database: PlanetScale
• Node.js version: 18.7.0

Prisma Version

4.10.0

[kelbyfaessler]

I wonder if this is related to #15958

[kelbyfaessler]

I don't even necessarily need a solution to this problem (although I'll take one if you have it). I just need some ways to debug what is going wrong because right now I don't have any ideas besides reading prisma source code, since that's most of the stacktrace.

Speaking of stacktrace, here it is:

InvalidDatasourceError: Datasource "db" references an environment variable "DATABASE_URL" that is not set
    at Ar.resolveDatasourceURL (<myproject>/node_modules/@prisma/client/runtime/edge.js:25:8662)
    at Ar.extractHostAndApiKey (<myproject>/node_modules/@prisma/client/runtime/edge.js:25:7743)
    at new DataProxyEngine (<myproject>/node_modules/@prisma/client/runtime/edge.js:25:3535)
    at t.getEngine (<myproject>/node_modules/@prisma/client/runtime/edge.js:88:3273)
    at new PrismaClient (<myproject>/node_modules/@prisma/client/runtime/edge.js:88:2867)
    at <myproject>/src/lib/server/prisma.ts:4:34
    at async instantiateModule (file://<myproject>/node_modules/vite/dist/node/chunks/dep-3007b26d.js:52400:9)

[kelbyfaessler]

I just created a new sveltekit skeleton project, added prisma with a single table in the schema, confirmed I could query the database (planetscale) with an actual row of data, then switched to the prisma edge client and it stopped working with the same env var error message above.

This definitely appears to be a prisma issue with sveltekit/planetscale

[jkomyno]

Hi @kelbyfaessler, this issue is indeed a duplicate of #15958, so I would close this new issue and redirect future communications there.

This seems to be one possible workaround, but we're currently looking for better solutions.

[kelbyfaessler]

Hi @jkomyno, would you mind sharing your reasoning for why you think this is a duplicate?

[kelbyfaessler]

A minimal example that reproduces the issue:

https://github.com/kelbyfaessler/prisma-env-var

[janpio]

I see no connection to Cloudflare either.

The edge Client does not load the .env file. Does it work if you manually set the environment variable? Or load it via dotenv-cli first when starting your server?

[kelbyfaessler]

@janpio it works if I pass the env var to the client constructor like in the CF issue thread. Not sure why that would make a difference, especially for local dev, but it does.

Still trying to get deployment to vercel edge functions working (also has errors)

[kelbyfaessler]

The deployment to vercel edge functions now works with the same solution of passing database url env var to the prisma client constructor like this:

import { DATABASE_URL } from "$env/static/private";

  new PrismaClient({
    datasources: {
      db: {
        url: DATABASE_URL
      }
    }
  });

But the issue remains for why it's necessary to do that when switching to the edge client

[ticup]

I had the same problem, the proposed workaround works, thanks.

[janpio]

@kelbyfaessler I took another look at this, and the explanation is much simpler:

• @prisma/client loads the .env file and makes its values available as environment variables.
• @prisma/client/edge is designed for edge environments where no files can be accessed or read, so it does not try to interact with the .env file at all.

So when using @prisma/client/edge in your app you have to load the environment variables some other way, and they will be available in your code:

• In deployment platforms like Lambda, Netlify or Vercel Serverless Functions you can define the environment variables via some UI - and they are then available in process.env to your app, which Prisma will read.
• In some other deployment environments like Cloudflare Workers (with the module workers) you do not get the environment variable values you defined in process.env, but in e.g. a param of your handler. In those cases you need to programmatically override the url in the PrismaClient() constructor.
• And finally, locally or in other environments where you don't have a nice UI, you need to set it outside of your app for the whole system, or use something like dotenv-cli before you execute your app.

That means that on Vercel Edge Functions for example the workaround you posted above should not be necessary.

[janpio]

And to show with your reproduction repository you provided (Thank you!):

gitpod /workspace/prisma-env-var (main) $ npm run dev

> prisma-env-var@0.0.1 dev
> vite dev


Forced re-optimization of dependencies

  VITE v4.2.1  ready in 721 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h to show help
5:44:38 PM [vite] Error when evaluating SSR module /src/lib/server/prisma.ts:

5:44:38 PM [vite] Error when evaluating SSR module /src/routes/+page.server.ts:

Internal server error: Datasource "db" references an environment variable "DATABASE_URL" that is not set
      at Rr.resolveDatasourceURL (/workspace/prisma-env-var/node_modules/@prisma/client/runtime/edge.js:25:8817)
      at Rr.extractHostAndApiKey (/workspace/prisma-env-var/node_modules/@prisma/client/runtime/edge.js:25:7898)
      at new DataProxyEngine (/workspace/prisma-env-var/node_modules/@prisma/client/runtime/edge.js:25:3637)
      ...

gitpod /workspace/prisma-env-var (main) $ npm install -g dotenv-cli

added 10 packages in 1s

2 packages are looking for funding
  run `npm fund` for details
gitpod /workspace/prisma-env-var (main) $ dotenv npm run dev

> prisma-env-var@0.0.1 dev
> vite dev



  VITE v4.2.1  ready in 715 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h to show help
5:45:12 PM [vite] Error when evaluating SSR module /src/lib/server/prisma.ts:

5:45:12 PM [vite] Error when evaluating SSR module /src/routes/+page.server.ts:

Internal server error: Datasource URL must use prisma:// protocol when --data-proxy is used
      at Rr.extractHostAndApiKey (/workspace/prisma-env-var/node_modules/@prisma/client/runtime/edge.js:25:8104)
      ...

First it fails as you describe. Then I install dotenv-cli and use it before the start command - and it complains that the DATABASE_URL is mysql:/... instead of prisma://... 😆

And if I set the value in .env to DATABASE_URL=prisma://foo?api_key=123 we get this:

gitpod /workspace/prisma-env-var (main) $ dotenv npm run dev

> prisma-env-var@0.0.1 dev
> vite dev



  VITE v4.2.1  ready in 741 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h to show help
Error: 
Invalid `prisma.star.findMany()` invocation:


Cannot fetch data from service:
getaddrinfo ENOTFOUND foo
    at Yn.handleRequestError (/workspace/prisma-env-var/node_modules/@prisma/client/runtime/edge.js:88:6681)
    at Yn.handleAndLogRequestError (/workspace/prisma-env-var/node_modules/@prisma/client/runtime/edge.js:88:6110)
   ... 

So it definitely gets the correct value with the simple, unmodified new PrismaClient().

[janpio]

(Closing this issue now as @prisma/client/edge works as expected - we will still try to improve this situation of course)

(@kelbyfaessler @ticup Please still let me know if you agree and understand all of this! I just close the issue so we know which ones we actually have to fix something, not to get rid of you.)