Wrangler Local Dev Broken
Ah, 3.84.1 works locally? Does it cooperate with local dev against a remote connection string?
25 Replies
Moving this to a thread so I can keep things straight
3.84.1 works with localhost db
but with remote neon db it does show
Even if my connectionString is
WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_DB="postgresql://repguide_owner:[email protected]/repguide?sslmode=require"
So it doesn't take sslmode I set into considerationNo,
workerd interpolates. I wonder if this is the workerd change, then.Correction, 3.85.0 also works, but only with localhost
So it seems like > 3.86.0 breaks
Okay so my guess
<= 3.85.0 only works with
localhost connectionString
>= 3.86.0 doesn't work with any connectionString -> timeoutsCan confirm 3.85.0 works locally for me as well
I've messaged the team, and we'll take a look. Thank you.
Thanks for taking a look so quick. And glad to hear that the intended behavior is, that even remote connection strings should be supported, so we can use solutions like Neon for development 🙂
Definitely, we want you to be able to use remote db's for dev, we added this a few versions ago
@alex (he/him) @Slylencer while we investigate local dev, just making sure you're unblocked since npx wrangler dev --remote is working
For me not really. We have an architecture with multiple workers connected with service bindings to use RPC calls, that doesn't seem to work if we use
--remote, since it doesn't find the scripts anymoreI'm fine
This looks also partially related: https://github.com/cloudflare/workers-sdk/issues/7255
Good catch. I've already opened up a revert to get us back to the prior state (https://github.com/cloudflare/workerd/pull/3148).
We'll take another run at it working with remote DBs when we can.
GitHub
Build software better, together
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.
So this brings us back to the <= 3.85.0 behavior, which didn’t support remote db's for devs?
For the time being, yes
also same issue for me - 3.85 works.
@AJR I know that’s hard to tell. But any ETA when to expect the reimplementation of the remote db support. I’m in the middle of migration a clients full backend architecture to CF. And it is planned to be finished by end of December. Would be great to at least be able to tell the client when it will work with remote db.
It's not something I anticipate having cycles to tackle in December. I'd say, likely, it's something we'll try to fit into Q1. I can't promise anything here though, will need to coordinate with product a bit.
The original behavior, with local dev on local DBs, will be restored with the next workerd release
Fixed in wrangler
3.92.0 - https://discord.com/channels/595317990191398933/1150557986239021106/1313664518144131122@elithrar This restores local support. It does not add remote DB support, as most remote DB options do not work with sslmode=disable
Yes sorry - this is just the local only fix
(The title of this thread was local dev)
Understood.. we really need remote db support though
Thanks @alex (he/him) . We do intend to support this, and it's something we're investigating. For the time being, are you unblocked if you toggle between your direct connection string and the hyperdrive connection string based on if you are in local dev vs production env?
Thanks for asking. Our client driver settings are a bit different between Hyperdrive and direct connection string, e.g. conneting to Hyperdrive doesn't support ssl enabled, so we would need to add more conditional logic. But we can investigate this for sure, if the support will take a longer time to implement
It will take some time to implement and we can't confidently give out a timeline at this time
Okay then we will need to investigate a workaround