Phoenix and URL hostname

Phoenix
1

I followed the guide Deploy an Elixir Phoenix Application which was great, everything went smoothly and I have my app deployed, but I figured out from within Phoenix, when I generate a route using route helpers like Routes.live_url(MyApp.Endpoint, AppLive), this constructs the url with the internal Fly name, as done so here (Deploy an Elixir Phoenix Application). That is not ideal, so I changed the url option in MyApp.Endpoint to my domain instead.

That works, BUT I just found out that this introduces another issue. When I deploy my app now and it runs the release command release_command = "/app/bin/my_app eval MyApp.Release.migrate", Ecto now fails to see the database. I tested it out and I can see that if I change it back to Fly’s "#{app_name}.fly.dev" it works. I figured this has to do with how Fly’s internal networking work, so what can I do here?

To clarify again, my main goal is to generate URLs with my app’s domain name, not Fly’s name.

Thanks team!

EDIT: Here’s the Ecto error:

15:21:25.507 [error] Could not create schema migrations table. This error usually happens due to the following:
           * The database does not exist
           * The "schema_migrations" table, which Ecto uses for managing
             migrations, was defined by another library
           * There is a deadlock while migrating (such as using concurrent
             indexes with a migration_lock)
         To fix the first issue, run "mix ecto.create".
         To address the second, you can run "mix ecto.drop" followed by
         "mix ecto.create". Alternatively you may configure Ecto to use
         another table and/or repository for managing migrations:
             config :habitat, Habitat.Repo,
               migration_source: "some_other_table_for_schema_migrations",
               migration_repo: AnotherRepoForSchemaMigrations
         The full error report is shown below.
         ** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 2978ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
           1. Ensuring your database is available and that you can connect to it
           2. Tracking down slow queries and making sure they are running fast enough
           3. Increasing the pool_size (albeit it increases resource consumption)
           4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
         See DBConnection.start_link/2 for more information
             (ecto_sql 3.6.1) lib/ecto/adapters/sql.ex:749: Ecto.Adapters.SQL.raise_sql_call_error/1
             (elixir 1.12.1) lib/enum.ex:1553: Enum."-map/2-lists^map/1-0-"/2
             (ecto_sql 3.6.1) lib/ecto/adapters/sql.ex:836: Ecto.Adapters.SQL.execute_ddl/4
             (ecto_sql 3.6.1) lib/ecto/migrator.ex:645: Ecto.Migrator.verbose_schema_migration/3
             (ecto_sql 3.6.1) lib/ecto/migrator.ex:473: Ecto.Migrator.lock_for_migrations/4
             (ecto_sql 3.6.1) lib/ecto/migrator.ex:388: Ecto.Migrator.run/4
             (ecto_sql 3.6.1) lib/ecto/migrator.ex:146: Ecto.Migrator.with_repo/3
2

That’s really surprising, you’d think the url option wouldn’t effect the repo. @Mark might have an idea of what’s up here.

3

Mhm actually turns out this might not be the cause, I tried to deploy again and tried to replicate what I did earlier that made it work, which is settings the url back like so:

 config :habitat, HabitatWeb.Endpoint,
    server: true,
    # url: [host: "habitfortodoist.com", port: 80],
    url: [host: "#{app_name}.fly.dev", port: 80],

This does not work anymore… I still get the same error, I also tried to increase Ecto’s POOL_SIZE which didn’t work either. Strange, it seems to be failing intermittently :confused: what else can I do to debug here?

4

Can you give it another try? I just checked and there were some stale DB DNS entries, so it’s possible the migration was trying to connect to an IP that no longer worked.

5

Awesome that worked, thanks! Does this happen often, and is it something I can fix/refresh on my end?

6

Not often, it’s a bug on our end that should go away soon. I don’t think there’s a way for you to fix it with flyctl, sadly.