As part of a global workaround, I’m looking to allocate an IPv4 address in the ORD region. However, the allocate-v4 command is throwing an unknown error:
fly ips allocate-v4 --region ord
Error An unknown error occurred.
Is something wrong here? User error? Any help is appreciated!
I’m not sure if you’ve since got this working but there were some recent API issues which may be related.
May be worth trying again to see if that was the cause.
This is not user error, we just don’t have IP blocks specifically for Chicago yet. Try running fly ips allocate-v4 --region iad and see if you have any luck?
We have regional IPs in iad, lhr, nrt, scl, sea, sin, syd right now.
This is not user error, we just don’t have IP blocks specifically for Chicago yet.
Ah, that’s a bummer. The idea here was to make a subdomain for that specific IP address and use that as a workaround for a particular part of the app that doesn’t work well globally due to websockets. Using replay to shift requests over to ORD works fine for the base HTTP requests, but doesn’t work for the subsequent websocket connection.
I’ll work on an alternative solution then 
Replay isn’t working with websockets?! It should be, that’s a bug on our end.
Actually, are you returning a replay response before the websockets upgrade?
Yes, it’s at the “middleware” (plug) level. The upgrade request itself is replayed to the primary region. When I mentioned this to Chris a few weeks back he seemed to think this was expected behavior, but I may not remember correctly.
For a little more context, the app/page I’m talking about is the Oban Web demo (a LiveView application) hosted at https://getoban.pro/oban.
For LiveView apps, you might be better off allowing the websocket everywhere, then bundling all queries together into a single method call, maybe on a context. Then use fly_rpc_elixir to call that method in the region you want.
If this was a bespoke LiveView app where we had complete control and could make use of RPC calls (which we do elsewhere in the app) then we would. The demo is a stand-alone LiveView that is more generic and meant to be deployed/used in a variety of environments, not just fly.
Right, that makes sense. I can see not wanting a fly_rpc dependency there. It should actually work fine, though, it’s just a noop if it’s not running with the environment variables it expects.