You don’t need to manage the pool in the client. Further, because Workers are typically short lived,

You don’t need to manage the pool in the client. Further, because Workers are typically short lived, your “pool” wouldn’t last any longer than your Worker invocation. Hyperdrive’s pooling is much, much more robust.

JJames Looks like there's some exciting new developments in the Cloudflare dashboard fo...

Sam•12/8/23, 3:23 PM

Letsgoooo, finally! Thanks team

MMax (@rozenmd)can you file a feature request for that? https://github.com/cloudflare/workers-s...

Mitya•12/8/23, 5:44 PM

Will do.

MMatt Silverlock You don’t need to manage the pool in the client. Further, because Workers are ty...

Mitya•12/8/23, 5:44 PM

Great! Thanks.

MMax (@rozenmd)can you file a feature request for that? https://github.com/cloudflare/workers-s...

Mitya•12/8/23, 5:47 PM

https://github.com/cloudflare/workers-sdk/issues/4578

Mitya•12/8/23, 5:53 PM

Is it possible to load one TOML in local dev and another for live? I'm aware that the TOML files supports environments, but I'm trying to circumvent this issue. Guess not if the file must be named exactly

wrangler.toml

wrangler.toml

Max (@rozenmd)•12/8/23, 6:08 PM

you can pass a path to the config file

Max (@rozenmd)•12/8/23, 6:09 PM

--config
https://developers.cloudflare.com/workers/wrangler/commands/

Commands - Wrangler · Cloudflare Workers docs

Create, develop, and deploy your Cloudflare Workers with Wrangler commands.

Mitya•12/8/23, 6:13 PM

Ah, interesting

Mitya•12/9/23, 12:50 AM

Hi again. My Worker needs to access multiple DBs. Can I set up multiple Hyperdrives under one worker, and how would I model/reference these in the TOML file?

kian•12/9/23, 3:09 AM

Just repeat the [[hyperdrive]] block

Kkian Just repeat the [[hyperdrive]] block

Mitya•12/9/23, 1:48 PM

Right - and then assign a different value to each

binding

binding

param within it, and reference those in my JS to denote which DB to connect to, right?

Mitya•12/9/23, 2:35 PM

When running my worker on CF, for endpoints that talk to Hyperdrive I get an error if I refresh the page soon after getting a response. This seems to happen only for routes that talk to HD, not ones that output a simple, static response. The error is:

A hanging Promise was canceled. This happens when the worker runtime is waiting for a Promise from JavaScript to resolve, but has detected that the Promise cannot possibly ever resolve because all code and events related to the Promise's I/O context have already finished. ✘ [ERROR] Uncaught (in response) Error: The script will never generate a response.

A hanging Promise was canceled. This happens when the worker runtime is waiting for a Promise from JavaScript to resolve, but has detected that the Promise cannot possibly ever resolve because all code and events related to the Promise's I/O context have already finished. ✘ [ERROR] Uncaught (in response) Error: The script will never generate a response.

Any idea what that might be about?

kian•12/9/23, 2:55 PM

Do you have code that reproduces the error?

kian•12/9/23, 2:55 PM

It sounds like you have I/O happening outside of the

fetch

fetch

(or other handlers).

Mitya•12/9/23, 3:15 PM

It seems (thanks to @PurpleBlob ) I was reusuing a DB client. I'm in the process of adapting my app from Express.js use, and hadn't properly changed this part to create a DB client on a per-request basis. So all fixed. Thanks anyway.

jjjrmy•12/10/23, 10:26 PM

I can't wait to try this!

piffie•12/11/23, 9:06 AM

hey guys - is there a clear docu about localconnectionstring? when i run the worker in local mode it tells me i need to add one - does this string has to be fully text, or can i use env variables in it as well? I really dont like to put passwords in the code.

kian•12/11/23, 9:57 AM

It’s just a string.

piffie•12/12/23, 7:32 PM

hmm... so now i have it configured exactly like in the example, but when i launch wrangler dev --remote it tells me Unexpected fields found in top-level field: "hyperdrive"

kian•12/12/23, 7:33 PM

What version is Wrangler?

piffie•12/12/23, 7:37 PM

figured it out - if you never deployed your worker, then its not working. you need to deploy it once to the server, and then the dev --remote works

Rreajim ERROR to create a hyperdrive config: has logined as admin user ``` npx wrangler...

Cyb3r-Jak3•12/13/23, 12:50 PM

You should log out and back in so wrangler can update its permissions as the message says.

kian•12/13/23, 7:29 PM

Do you have a Workers Paid plan?

kian•12/13/23, 7:39 PM

Yeah, you need a paid plan for Hyperdrive.

Sam•12/14/23, 2:02 PM

Is it possible to leave ideas for the Hyperdrive dashboard here? If so, it would be great to add a small (readable) name/description to each Hyperdrive. This will make it more clear for what the Hyperdrive connection is being used. Thanks

Max (@rozenmd)•12/14/23, 2:28 PM

Always feel free to leave feature requests/feedback here MeowHeartCloudflare

Sam•12/14/23, 4:45 PM

What is more recommended while using Hyperdrive?

Opening a connection w/ a query:

const connection = await client.connect()
await connection.query(``)
ctx.waitUntil(connection.end())

const connection = await client.connect()
await connection.query(``)
ctx.waitUntil(connection.end())

Or just simply using Pooling?

pool.query(``)

pool.query(``)

kian•12/14/23, 4:47 PM

client

client

is fine

kian•12/14/23, 4:47 PM

Hyperdrive will manage a pool of connections for you.

Sam•12/14/23, 4:48 PM

I'm getting the following without opening a connection: Error: The script will never generate a response.

kian•12/14/23, 4:48 PM

Do you have code to reproduce it?

kian•12/14/23, 4:48 PM

That usually means you're doing stuff in the global scope, which is a no-go in Workers.

Sam•12/14/23, 5:12 PM

I think I know what I'm doing wrong lmao. I'm developing locally, so it's in no way connected through Hyperdrive. So I need to open the connection first

Sam•12/14/23, 6:15 PM

Ok that's not the reason, it's not working in production either. Creating a thread to paste the code. (Sorry for tagging: @kian)

Mitya•12/14/23, 6:18 PM

I have an issue which may or not be related to @Sam's. I've set up a Hyperdrive, but when I run locally, I get an error from PG that , even though I'm connecting to a publicly-accessible (albeit remotely-hosted) DB. Other apps on my local machine not using CF can connect to it fine, as can a local DB client I use. The connection string is definitely correct. If I run the app with

--remote

--remote

it does connect. Anyone any idea here?

MMitya I have an issue which may or not be related to @Sam's. I've set up a Hyperdrive,...

Sam•12/14/23, 6:19 PM

It's not related to mine, the "HYPERDRIVE" environment variable is not being filled developing locally. You need to do this yourself

Mitya•12/14/23, 6:20 PM

Not sure I follow. My TOML has:

Mitya•12/14/23, 6:20 PM

Shouldn't that work locally? The guide suggests that's what's needed.

Sam•12/14/23, 6:22 PM

Ah yeah, I'm using another way by putting it in my .dev.vars. Don't want my connection string exposed in the wrangler.toml file. But still not related to my issue

Mitya•12/14/23, 6:24 PM

Ahh OK, gotcha. Re: not exposing the connection string, I faced the same issue. I found that if I put my connection string in my

.dev.vars

.dev.vars

Wrangler error'd on startup, it had to be in the TOML. So in the end I set up two TOMLs -

wrangler.toml

wrangler.toml

and and just pointed my dev script to the latter via the

--config

--config

arg.

Mitya•12/14/23, 6:29 PM

Anyway, good luck with your issue. Hopefully someone from CF (@kian?) can help with the above as it's proving a pain!

kian•12/14/23, 6:31 PM

I’m just a community member but I agree that it’s a bit of an odd pattern, the traditional guidance is that everything in Wrangler.toml is safe to commit to VCS & secrets are either stored on the edge or in .dev.vars

Kkian I’m just a community member but I agree that it’s a bit of an odd pattern, the t...

Sam•12/14/23, 6:31 PM

I think we're both talking about publishing to Github

Mitya•12/14/23, 6:31 PM

Sorry I meant the PG IP error issue when I run locally not via

--remote

--remote

A hanging Promise was canceled. This happens when the worker runtime is waiting for a Promise from JavaScript to resolve, but has detected that the Promise cannot possibly ever resolve because all code and events related to the Promise's I/O context have already finished. ✘ [ERROR] Uncaught (in response) Error: The script will never generate a response.