Run phx.server after seeds with mix alias

Hello there,

I’m trying to define a mix alias to clear, recreate and seed my database before starting the phoenix server.

Here is my alias config:

  defp aliases do
    [
      "ecto.setup": ["ecto.create", "ecto.migrate", "run priv/customer_repo/seeds.exs --no-halt"],
      "ecto.reset": ["ecto.drop", "ecto.setup"],
      seededserver: ["ecto.reset", "phx.server"],
      test: ["ecto.create --quiet", "ecto.migrate", "test"]
    ]
  end

When I run mix seededserver, everything goes very well up to the seeds. Once they are executed, nothing happens. It’s like phx.server isn’t called. However, elixir doesn’t quit either. The VM just hangs on. Emptying my seeds script doesn’t change anything. If I remove phx.server, elixir quits normally, and if I remove the call to the seeds script, phx.server runs normally.

I’ve tried many different things, I’ve read the docs, but I can’t wrap my head around this. I feel like I can’t see the elephant in the room, and I don’t know why.

Thanks for your help, strangers.


EDIT: to be clear, I would just like to understand technically why phx.server can’t be run after the seeds script.

Hi and welcome,

I am not sure why You would want to link the reset of your database with the start of your server.

I also prefer to start my dev server with…

$ iex -S mix phx.server

… because it allows direct interaction with console.

Anyway, I am not sure what You expect, but when You run mix phx.server, the shell is blocked. until You kill the server.

Hi,

Do you want too reseed the test database at each restart? or what are you trying to reset?

My seededserver alias is for a special case where I test my dev config in a clean environment using docker. I fire up my code in a container along with postgres and other services and want to have an environment ready (which means: with seeds) for manual tests.

I really don’t see why this wouldn’t work.

I don’t know if you heard but there is a book written by the authors of phoenix and elixir where they explain the whole framework and build an app with tests seeds and so on. Also they explain that the seed happens once you don’t need to reset anything only if you wnat to add new data. But if you have a unique constraint in place it shouldn’t be a problem.

The book is programming phoenix 1.4, you can’t also get a discount using the forum partnership with praprog.

Thanks for the tip, I’ll sure check this book out!

However, my question is still unanswered. Be it a good or bad idea, I don’t see why my config wouldn’t work.

OK i will give you my point of view:

Why would I reset my database at each server startup when can i have my data there to use it right away when I don’t have any new data to add to the db?

So I have my article data for example I can use it

and then need to shutdown the server to add a new feature, but this feature doesn’t affect my data that i need so why would I reset my database, when i turn the server back again. if i already have my data there?

So it’s is pointless to reset your data at each server restart and costly that is the bottom line.

If you want to go fully clean on every start up you can remove your PostgreSQL volume from Docker so that when the container dies, all of your data is gone and the next time you start things up it’ll be a 100% fresh DB.

If you want volumes most of the time you can also run docker-compose down -v to wipe your DB, then the next time you docker-compose up, it’s a fresh slate. This is something I do a lot in my own projects when I’m generating fake data (and I’m actively testing the code to generate that fake data).

Then the problem reduces down to just seeding your DB on every start up.

Thanks but that’s not helping. I’m just looking for someone who understands precisely how aliases and mix work and can explain why this config is broken.

That’s what I do indeed. The problem is starting phx.server after the seeds. Although it might not be a recommended or usual practice, I would just like to understand why it doesn’t work.

You can always reverse the order. Drop the alias idea, and start Phoenix normally. Then create a Docker ENTRYPOINT script to run your seed file. That would execute every time the container starts.

Yep that’s the solution I was going to fall back on afterwards.
I just don’t see why it wouldn’t work with the alias.

Can you show the last few lines of your seeds.exs?

Also, did you try to access your phoenix app after the shell seemed to hang?

Can you show the output you get when you run mix seededserver? I tried on an app I have and phx.server should work fine as part of an alias. Do you get a message like: [info] Running MyAppWeb.Endpoint with cowboy 2.7.0 at 0.0.0.0:4000 (http)?

Alright so here is a precise example with the output I get.

I stripped down the seeds file because it’s quite big (it doesn’t change anything about the bug anyway):

# Script for populating the database. You can run it as:
#
#     mix run priv/customer_repo/seeds.exs
#

account_admin_email = "admin@client.com"
Client.Factory.insert(:account, email: account_admin_email, role: "admin")

Here is the output I get (a little bit reduced):

graph_api       | Generated client app
graph_api       | The database for Client.CustomerRepo has been dropped
graph_api       | The database for Client.CustomerRepo has been created
graph_api       | [info] == Running 20190529062333 Client.CustomerRepo.Migrations.CreateAccounts.change/0 forward
graph_api       | [info] create table accounts
graph_api       | [info] create index accounts_email_index
graph_api       | [info] == Migrated 20190529062333 in 0.0s
(more migrations...)
graph_api       | [error] `inotify-tools` is needed to run `file_system` for your system, check https://github.com/rvoicilas/inotify-tools/wiki for more information about how to install it. If it's already installed but not be found, appoint executable file with `config.exs` or `FILESYSTEM_FSINOTIFY_EXECUTABLE_FILE` env.
graph_api       | [warn] Could not start Phoenix live-reload because we cannot listen to the file system.
graph_api       | You don't need to worry! This is an optional feature used during development to
graph_api       | refresh your browser when you save files and it does not affect production.
graph_api       | 
graph_api       | [info] [MQTT] Connection has been established
graph_api       | [info] [MQTT] Subscribed to echo
graph_api       | [debug] QUERY OK db=4.9ms queue=1.5ms
graph_api       | INSERT INTO "accounts" ("email","name","password_hash","role","inserted_at","updated_at") VALUES ($1,$2,$3,$4,$5,$6) RETURNING "id" ["admin@client.com", "Name #0", "$2b$12$ROLGMyua5K5OYuL0hiSEQuNkM.bgWfEBbBcXdYjq8Z2aPZ7Hyuqbm", "admin", ~N[2020-01-21 08:28:43], ~N[2020-01-21 08:28:43]]
graph_api       | [debug] Tzdata polling for update.
graph_api       | [info] tzdata release in place is from a file last modified Tue, 26 Mar 2019 05:40:14 GMT. Release file on server was last modified Wed, 11 Sep 2019 19:35:17 GMT.
graph_api       | [debug] Tzdata downloading new data from https://data.iana.org/time-zones/tzdata-latest.tar.gz
graph_api       | [debug] Tzdata data downloaded. Release version 2019c.
graph_api       | [info] Tzdata has updated the release from 2019a to 2019c
graph_api       | [debug] Tzdata deleting ETS table for version 2019a
graph_api       | [debug] Tzdata deleting ETS table file for version 2019a

And I can’t even open a TCP connection with the server.

Now if I set up my alias like this:

seededserver: ["ecto.drop", "ecto.create", "ecto.migrate", "phx.server"]

What I get is:

graph_api       | Generated client app
graph_api       | The database for Client.CustomerRepo has been dropped
graph_api       | The database for Client.CustomerRepo has been created
graph_api       | [info] == Running 20190529062333 Client.CustomerRepo.Migrations.CreateAccounts.change/0 forward
graph_api       | [info] create table accounts
graph_api       | [info] create index accounts_email_index
graph_api       | [info] == Migrated 20190529062333 in 0.0s
(more migrations...)
graph_api       | [error] `inotify-tools` is needed to run `file_system` for your system, check https://github.com/rvgraph_api       | [warn] Could not start Phoenix live-reload because we cannot listen to the file system.
graph_api       | You don't need to worry! This is an optional feature used during development to
graph_api       | refresh your browser when you save files and it does not affect production.
graph_api       | 
graph_api       | [info] Running ClientWeb.Endpoint with cowboy 2.6.3 at 0.0.0.0:4000 (http)
graph_api       | [info] Access ClientWeb.Endpoint at http://localhost:4000
graph_api       | [info] [MQTT] Connection has been established
graph_api       | [info] [MQTT] Subscribed to echo
graph_api       | 
graph_api       | webpack is watching the files…
graph_api       | 
graph_api       | [debug] Tzdata polling for update.
graph_api       | [info] tzdata release in place is from a file last modified Tue, 26 Mar 2019 05:40:14 GMT. Release file on server was last modified Wed, 11 Sep 2019 19:35:17 GMT.
graph_api       | [debug] Tzdata downloading new data from https://data.iana.org/time-zones/tzdata-latest.tar.gz
graph_api       | [debug] Tzdata data downloaded. Release version 2019c.
graph_api       | [info] Tzdata has updated the release from 2019a to 2019c
graph_api       | [debug] Tzdata deleting ETS table for version 2019a
graph_api       | [debug] Tzdata deleting ETS table file for version 2019a
graph_api       | Hash: 2d405c93b037ae7d7107
graph_api       | Version: webpack 4.41.5
graph_api       | Time: 8763ms
graph_api       | Built at: 01/21/2020 8:39:14 AM
graph_api       |                                             Asset       Size    Chunks             Chunk Names
graph_api       |                                  ../css/admin.css    543 KiB     admin  [emitted]  admin
graph_api       |                                    ../favicon.ico   1.23 KiB            [emitted]  
graph_api       |              ../fonts/admin/Simple-Line-Icons.eot     53 KiB            [emitted]  
graph_api       |              ../fonts/admin/Simple-Line-Icons.ttf   52.8 KiB            [emitted]  
graph_api       |              ../fonts/admin/Simple-Line-Icons.txt    233 KiB            [emitted]  
graph_api       |             ../fonts/admin/Simple-Line-Icons.woff   79.4 KiB            [emitted]  
graph_api       |            ../fonts/admin/Simple-Line-Icons.woff2   29.4 KiB            [emitted]  
graph_api       |                               ../images/.DS_Store      6 KiB            [emitted]  
graph_api       |                     ../images/auth-background.jpg   1.01 MiB            [emitted]  
graph_api       |                     ../images/auth-background.png    416 KiB            [emitted]  
graph_api       |                  ../images/avatar-placeholder.jpg   36.7 KiB            [emitted]  
graph_api       |                     ../images/home-background.jpg   68.6 KiB            [emitted]  
graph_api       |                                ../images/logo.png   2.86 KiB            [emitted]  
graph_api       |                                ../images/logo.svg   7.85 KiB            [emitted]  
graph_api       |           ../images/logo_for_white_background.png   7.42 KiB            [emitted]  
graph_api       |                             ../images/phoenix.png   13.6 KiB            [emitted]  
graph_api       |                                     ../robots.txt  202 bytes            [emitted]  
graph_api       |                                          32px.png   5.53 KiB            [emitted]  
graph_api       |                                          40px.png   2.17 KiB            [emitted]  
graph_api       |                                          admin.js    2.9 MiB     admin  [emitted]  admin
graph_api       | Entrypoint admin = ../css/admin.css admin.js
graph_api       | [0] multi ./js/admin.js 28 bytes {admin} [built]
graph_api       | [../deps/phoenix_html/priv/static/phoenix_html.js] 2.18 KiB {admin} [built]
graph_api       | [./css/admin.scss] 39 bytes {admin} [built]
graph_api       | [./js/admin.js] 502 bytes {admin} [built]
graph_api       | [./js/admin/components sync recursive ^(.*\.(js$))[^.]*$] ./js/admin/components sync ^(.*\.(js$))[^.]*$ 227 bytes {admin} [built]
graph_api       | [./js/common/components sync recursive ^(.*\.(js$))[^.]*$] ./js/common/components sync ^(.*\.(js$))[^.]*$ 237 bytes {admin}  [built]
graph_api       | [./js/common/theme/theme.js] 23.8 KiB {admin}  [built]
graph_api       | [./js/common/utils/webpack.js] 558 bytes {admin}  [built]
graph_api       | [./js/common/vendor sync recursive ^(.*\.(js$))[^.]*$] ./js/common/vendor sync ^(.*\.(js$))[^.]*$ 200 bytes {admin}  [built]
graph_api       | [./js/common/vendor/index.js] 255 bytes {admin}  [built]
graph_api       | [./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 472 bytes {admin}  [built]
graph_api       |     + 409 hidden modules
graph_api       | Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/postcss-loader/lib/index.js??ref--5-2!node_modules/sass-loader/dist/cjs.js??ref--5-3!css/admin.scss:
graph_api       |     Entrypoint mini-css-extract-plugin = *
graph_api       |     [./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/lib/index.js?!./node_modules/sass-loader/dist/cjs.js?!./css/admin.scss] ./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/lib??ref--5-2!./node_modules/sass-loader/dist/cjs.js??ref--5-3!./css/admin.scss 519 KiB {mini-css-extract-plugin} [built]
graph_api       |         + 4 hidden modules

axelson, does your seeds script return anything specific at the end?
Also, I run elixir 1.8.2 but tried with 1.9.4 and couldn’t witness any change.

So, have you tried installing inotify-tools as well, just in case?

The second output looks fine; you still can’t connect to the server?

Yeah I’ve added inotify-tools to my dockerfile but it didn’t change anything.
Of course the second output looks fine, I removed the seeds :slight_smile: I just wanted to demonstrate that the problem comes from the call to the seeds.