Known bug, the fix for that is releasing this week.
Known bug, the fix for that is releasing this week.
ASorry, I'm not following. Historically Hyperdrive has allowed 20 connections per region per Hyperdrive. What maximum are you referring to?
LThe maximum is 25 (right now I've 24, but I can see only 20)
AWhat maximum?
LThe quantity of Hyderdrive objects
AOh, you're referring to the number of Hyperdrive configs! Sorry, took me a second.
You can use the list API to see them all.
You can use the list API to see them all.
Lbut with wrangler hyderdrive list I can't see all
LAPI list by postman you say?
ANot sure why wrangler would be truncating those, I'll check with the team.
Any http client really. I just use curl
Any http client really. I just use curl
LOkki! I need retrieve de config Id... I'll try
AList API for your account should return the IDs as part of the json
MYou should be able to see multiple pages of results now (in the dashboard)
LYeah, thanks!
DThere’s also nice typescript bindings now.
You can see me using them here: https://www.ai.moda/en/blog/automate-hyperdrive-iam-auth-with-workers
You can see me using them here: https://www.ai.moda/en/blog/automate-hyperdrive-iam-auth-with-workers
AThis is fixed now.
FYI also @dave | ai.moda
FYI also @dave | ai.moda
AHey all! Today we released the final step in a fairly large rearchitecture of Hyperdrive. We'll be getting into the details in a full length blog post a little down the road, but for now here are the takeaways.
- All newly created Hyperdrives will perform substantially more efficiently. This goes double for users with the origin database in APAC.
- This should primarily manifest as lower latencies and fewer disconnects.
- This will affect all Hyperdrives with or without caching.
- We will be backfilling this solution to existing Hyperdrives progressively, over the course of the next couple weeks, starting next Monday. If you want yours handled sooner, please feel free to message me or respond in a thread here.
DI've done some search on this channel and it seems like cache busting/purging is still WIP? I ran into a bug today that took me awhile to figure out it was being caused by hyperdrive - user creates a comment, the query client then invalidates the comments query, it refetches the stale data causing my optimistic comment to disappear. This makes sense given hyperdrive caching. I'm just curious as to what my workaround should be given that cache purging isn't a thing (yet).
DIt'd be a little contrived for me to add some volatile function to the query given that it'd have to originate from the client and then drill through the api router and modify queries in a weird way
AThe alternative is likely just a second hyperdrive config with caching disabled, and direct your queries to whichever is appropriate at the application level.
Not a great alternative, we're aware.
Not a great alternative, we're aware.
Diirc
ORDER BY random() will always cause a cache miss, though @AJR can confirm if that's correctDit'd also cause strange query results 
DStill no defined list of IP addresses that Hyperdrive connects from, right?
DTotally depends on what you're doing. If you are sorting by a date column, but are returning the date column anyway, you can sort it in JavaScript after.
DNot if you're paginating
DI just turned off caching for now, I'll wait until cache purging is shipped, I don't love modifying the application layer in weird ways to get expected query behavior
Dhmm, there's probably another trick you could use with random(). Like
WHERE random() >= 0;.DI think at that point it'd make more sense to just use a scond hyderdrive config with caching disabled for queries that you're doing that to
DIs there a reason why you aren't returning the comment in the same query where the user creates it?
DI am, but think about the user that gets a push notification and looks at their phone immediately, that comment won't be loaded in
Ddelay the notification by the cache duration?
DI think the two hyperdrive configs is a pretty good solution, since in my case it's really there's a set of resources that frequently are mutated and should never be cached, and sets of resources that can be cached
DCache purging would just allow optimization of this
ANope. Soon(tm), though.
Part of the reason that this is taking so long is that a bunch of folks went ahead and tried to allowlist based on the shared/untrusted ip pool. We don't want to just break them (though at some point they'll get broken anyway when the pool shifts enough to clip them, but at least it won't be because we did it). So the migration over is kind of a process.
Part of the reason that this is taking so long is that a bunch of folks went ahead and tried to allowlist based on the shared/untrusted ip pool. We don't want to just break them (though at some point they'll get broken anyway when the pool shifts enough to clip them, but at least it won't be because we did it). So the migration over is kind of a process.
D@AJR oh, another reason why exposing Hyperdrive as a regular PostgreSQL pooler would be great: we could do stacked Hyperdrive configs! e.g. one "main" Hyperdrive with no caching connected to the real backend directly, and then have another Hyperdrive config with caching enabled that connects to the main Hyperdrive's pooler.
DI think it's still worth using hyperdrive without caching though right?
Dyes.
AOh yeah. Measure how long it takes to create a connection to a pooler/origin further away than a couple hundred miles and you'll have a clear picture of why only ~half of our configs even having caching enabled.
AI really need to write that "how hyperdrive works" blog post soon. I'm finally allowed to.
AI'm hopeful we can get per-query cache bypass/adjustment done sooner than that would take.
DI'm pretty sure the answer to this is "heck no", but would it possible to have a unique outgoing port for each Hyperdrive config? (And I don't think it would be too insane, since it's only 25 ports per paid Workers account that would need to be "reserved".) Or even 1 unique port per account would be nice.
That would be really nice to firewall based off of.
That would be really nice to firewall based off of.
AHmmm. I'll ask the team, it's not something we've talked about afaik
DI would be curious if using Hyperdrive reduces bandwidth pricing (and by how much) for Google Cloud customers, since Cloudflare has a reduced bandwidth price iirc.
AThe goal is that it should, yes. Still needs some work to get all the way there, I believe. I don't work with that project a ton and there is some nuance IIRC.
Diirc it's already reduced pricing, no?
AIt gets complicated. It goes GCP->Workers->Hyperdrive for ingress, so I believe that's already reduced. Egress from ??->Workers->Hyperdrive->GCS is the one I'm not certain about.
DWorkers->Hyperdrive->GCS would be ingress from Google's standpoint (which is free)
DYou should be able to automatically tell who did the allowlist by trying to connect from a new IP. Then whoever fails, email them giving them a warning that they need to use the new proper official list of IP ranges. 
AWe landed with just never migrating them, plus courtesy email. Same difference, though.
Doh, is there a list already somewhere secret? 
AOf the shared address pool? Not publicly, but folks are clever. Hazard of making tools for other devs, I guess. In some regions things are stable enough that folks noticed that all Hyperdrive connections were coming in from a small number of addresses, and eventually just coded that into their firewall rules.
