My apologies - looks like I needed to specify the port in this scenario since we’re communicating internally: http://cube-api.internal:4000/cubejs-api
1 Like
Alright, correction…the queries don’t seem to work. Would the Cube API also need to be listening for IPv6? I feel like maybe we’re running in to the same type of binding problem again
Error: request to http://encore-cube-api.internal:4000/cubejs-api/v1/load?query=%7B%22measures%22:[%22ContactList.count%22]%7D
failed, reason: connect ECONNREFUSED fdaa:0:3778:a7b:87:af3d:22f0:2:4000
Just to confirm, now are CUBESTORE_HTTP_BIND_ADDR, CUBESTORE_BIND_ADDR, CUBESTORE_META_BIND_ADDR are all set to [::]:XXXX? Where XXXX is their respective ports?
yea the cubestore communication is all good, however, the Cube API instance exposes port 4000 so that you can publicly hit the API from your front end application (React), like so: https://encore-cube-api.fly.dev/cubejs-api/. This works and returns data as expected. However I have a server deployed on Fly called encore-graphql that also needs to request data from this API, so I thought I could run a request like http://encore-cube-api.internal:4000/cubejs-api to communicate internally, but that’s when I receive the error message above.
Can we get the startup logs for encore-cube-api? That should help see what the server is actually binding to.
PS. And which ENV var is set to [::]:4000? Is that CUBESTORE_BIND_ADDR? I’m wondering if this API is a different node js app.
PPS. Possibly cube.js/server.ts at 3b0c8d5886f47b5adbc6487a3aa10596a945cd77 · cube-js/cube.js · GitHub
Certainly (see below).
Regarding your PPS, that’s correct, the Cube API is a nodejs application. It’s the container called API Instance defined in the top left of the diagram of this message How to connect to a 3rd party image that listens for IPv4 addresses using Fly's private networking? - #3 by uncvrd
It looks like they only expose an ENV to modify which PORT it’s listening on, but cannot control the binding? That server.ts file was exactly what I was looking at too! Seems like that’s where the culprit lies. Right? However, that begs the question, if we were to modify that server.ts to bind to IPv6, would that affect how Fly handles an external query like https://encore-cube-api.fly.dev/cubejs-api/?
The CUBESTORE_BIND_ADDR is defined on the Cubestore Router in the diagram.
So we fixed the Router (which has the metastore) and pre-emptively fixed the worker, then.
Will raise a PR for the API as well. I suppose we’ll have to drag every application on the internet kicking and screaming into the IPv6 age at some point, this is as good a start as any 
Yea exactly! The internal communication between cubestore containers is 100% fixed, but looks like that API server still needs to be updated 
haha, I agree and as always, really appreciate your help with this.
So just to clarify, by binding the API server to IPv6, I’ll still be able to make a request from my React application via https://encore-cube-api.fly.dev/cubejs-api/ (which is a Fly domain mapped to an A IPv4 record)? I assume Fly handles the translation of an IPv4 request to an app with an internal_port=4000 that is bound to IPv6?
(…does that make sense?)
Yeah, a server with an IPv6 binding should also listen on IPv4, but we’ll have to double check that.
1 Like
Sounds good, fingers crossed! Also feel free to tag me on the github PR @uncvrd (same username as here) so I can check it out too
1 Like