Hit an unwrap() panic in datamodel-connector

[mojotalantikite]

I'm testing out using Prisma to connect to Amazon Aurora Postgres via a Lambda and hit an unexpected panic yesterday in our environment. I wanted to share this in case it helps surface anything.

In our local dev environments we're using the env("DATABASE_URL") variable to set our postgresql connection URL, but in our AWS environments we override this by passing the datasources.db.url to PrismaClient (in TypeScript). I'm creating this connection string by pulling the values from AWS Secrets Manager which are rotated with their official lambda. Here's the relevant part of our schema:

datasource db {
    provider = "postgresql"
    url      = env("DATABASE_URL")
}

generator client {
    provider      = "prisma-client-js"
    binaryTargets = ["native", "rhel-openssl-1.0.x"]
}

And here's the piece of code that's setting the connection URL in our lambda (excluded the surrounding):

const secret = await getSecretValue() // func that retrieves from secrets manager

        const postgresURL = `postgresql://${secret.username}:${secret.password}@${secret.host}:${secret.port}/${secret.dbname}?schema=public&connection_limit=5`

        const prisma = new PrismaClient({
            datasources: {
                db: {
                    url: postgresURL,
                },
            },
        })

etc...

Everything was working fine in our PR testing branches until the code went into our higher environments (as such things do). Our lambda started throwing panics:

thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: InvalidPort', /root/build/libs/datamodel/connectors/datamodel-connector/src/lib.rs:100:44

After going down a few unfruitful paths I figured there might be something wrong with the connection URL parsing, so I forced a rotation of the password in Secrets Manager just in case and... things started working fine again? Normal problematic characters are already excluded from the password string (e.g. :/@"') and I confirmed none of them were in the connection string that was causing issues, so I wasn't expecting that to work.

Anyway, I figure unwrap() is generally used in places where an error case isn't generally expected and wanted to raise this. I'm still not totally sure why rotating the secret ended up making things work. Thanks!

[janpio]

Do you maybe still have the password value that was causing this problem?

Seems to me that that it probably contained one of the characters that unfortunately would have needed to be escaped for usage in our connection strings (https://www.prisma.io/docs/reference/database-reference/connection-urls#special-characters). (Although that should definitely result in a higher level error than what you got)

[mojotalantikite]

So yeah, the password that caused the issue did have a non-escaped % in it which likely was the problem. We fixed secrets manager to exclude additional characters that could cause problems.

Just wanted to report it because I figured that error probably should have been higher level and maybe something was being missed in validation somewhere. Thanks!

[janpio]

Thanks for confirming this - we should definitely have a (much) better error message here and definitely not an unwrap. We will try to reproduce this with % in a password and see if we get the same error message.