-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Node 17+ localhost resolution #21
Comments
With the latest v0.4.0 release, the original fetch error is properly stored and now will be visible in the stack trace. Additionally, all |
Closed
Does this not complicate auth via providers that require localhost in the callback ? (e.g. Microsoft) 🤔 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is related to pocketbase/pocketbase#258 and pocketbase/pocketbase#272.
In short, when the PocketBase backend is started with the default
localhost:8090
address, the go dns resolver will return first the IPv4 address (aka.127.0.0.1
), and then, if available, the IPv6 version (aka.[::1]
).Node17+ for some reason favors the opposite (IPv6 first, then IPv4) and therefore when you initialize the SDK client using the
localhost
address, eg:it could actually resolve to the IPv6 version (
[::1]
) and will result in connection failure (because the PocketBase backend will be binded only to the IPv4 version).To fix this, you could simply provide explicitly the IPv4 localhost address, aka:
Since there isn't much we can do from the backend side (unless we bind to both ipv4 and ipv6 or to
0.0.0.0
), we'll have to improve the SDK error reporting to make it more clear what could be the reason behind the connection failure.The text was updated successfully, but these errors were encountered: