This is great! Out of interest, what was it set to before the change?
This is great! Out of interest, what was it set to before the change?
SET search_path .. command but I believe that does not work... it being a session config and clients don't stay on a session.ALTER ROLE for the user you have set up for your Hyperdrive. That's the canonical Postgres approach and should fit well with Hyperdrive basically functioning like any other user.The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response. Refer to: https://developers.cloudflare.com/workers/observability/errors/or this one:
Promise will never complete.The requests timeout and fail obviously but the worker is stupid simple (it fails at 3ms CPU time and 60s wall time so it's obviously waiting for something external) and I have never seen this error on "normal" workers (those not interacting with Hyperdrive) before.
fetch handler so I would expect a new "pool" every request and the old one discarded but who knows what it actually does under the hood SELECT x, y, z FROM myTable LIMIT 1, and get a malformed response where you get 0 rows returned when you'd have expected 1 row?example.com (string) and second 1 (number)typeof for a succesful query was both object although I know realize this was a pretty pointless thing to check for... adding some more console logs of the actual contents of the result.select `id`, `uuid`, `team_id`, `domain`, `with_links`, `is_default`, `target`, `include_path`, `include_query`, `redirect_default_not_found` from `custom_domains` where `custom_domains`.`domain` = ? limit ?