** (RuntimeError) could not lookup Ecto repo Repo because it was not started or it does not exist

Hi! May someone helps me, please!

I have two apps into an umbrella project: the first one is Database, which manages queries, and the secon one is an app, which uses some functions from the Database app to check information from the database. I am getting the next error when trying to run tests for functions in the second one which uses functions from the Database app:

** (RuntimeError) could not lookup Ecto repo Repo because it was not started or it does not exist

and this is the setup that I have for my tests:

  setup do
    :ok = Ecto.Adapters.SQL.Sandbox.checkout(Repo)
  end
4 Likes

Does your second app have a dependency on the first one in its mix.exs?

No and yes. Actually I am trying to create a DDD project and Database app is a dependency of another which is conected to database and is in the middle of Database and the app that I want to test (The app that I want to test is not connected directly with database). It is something like this:

app_to_test -> app_that_connects -> Database

app_to_test has app_that_connects as dep

app_that_connects has Database as dep

app_to_test does not have Database as dep

We just solved this problem. In our case, the test database had unexpected data. (!!) It might have had a slightly different schema than expected.

The fix was to recreate the test database with MIX_ENV=test mix ecto.reset.

It was a frustrating experience.

4 Likes

I’m also experiencing this issue. and @dogweather’s solution didn’t help.
Can anyone please suggest how to fix this?
This is really weird.

My app is simple (non-umbrella) with the following relevant deps:
{:phoenix, “~> 1.5.1”},
{:phoenix_ecto, “~> 4.1”},
{:ecto_sql, “~> 3.4”},
{:postgrex, “>= 0.0.0”},

BTW, my OS :
Linux 4.15.0-1-amd64 #1 SMP Debian 4.15.4-1~mx17+1 (2018-02-23) x86_64 GNU/Linux

Distributor ID: MX
Description: MX 18.3 Continuum
Release: 18.3
Codename: Continuum

UPDATE: tried the following, but issue persists, preventing me from further development of my app:

mix deps.update --all   # Ok
mix ecto.reset    # Fail: this keeps throwing the same error (the current topic)

Also dropped both my_dev and my_test DBs via psql then ran mix ecto.reset to no success.

2 Likes

Hi has anyone resolve this issue.

I am getting this above mentioned issue, when building things and testing things in ci.

This comes up sometimes depending on how you are using your repo. Sometimes you just need to start it, e.g.

MyApp.Repo.start_link()
1 Like

I had an instance of this issue.

I was trying to use Repo.preload() inside of a plug call for my controller like

  plug Plugs.Setup, %{
    is_navigation?: false,
    items: Items.list_active_items() |> Repo.preload(:info),
  }

  def index(conn, params) do
     #do something, return conn
  end

My fix was to pass it in during the plug call.

def call(conn, settings) do
    map = %{
      items: Items.list_active_items() |> Repo.preload([:art_information, :inventory_info]),
    }

    Map.merge(map)
    |> Enum.reduce(conn, fn {key, value}, acc -> assign(acc, key, value) end )
  end

I believe I had this error because the link for the repo isn’t started before you get into an action.

Saved the day!

Dont know the cause yet, but ecto.reset seems to be only way to unblock this

I had quite a few of those while working on the test exercising upserts - Repo.insert(on_conflict: :nothing, returning: true, conflict_target: [:sku, :lastmod])

As soon as I was done with the test the error went away

Coming into a legacy umbrella project, the error message turned out to be pointing me in the correct direction to solve the problem:

mix.exs

  def application do
    [
      mod: {YourProjectWeb.Application, []}, # had to re-add this line to existing umbrella application
      extra_applications: [:logger, :runtime_tools]
    ]
  end

At some point, the supervision tree was disabled for whatever, I just needed to re-enable it. (Hopefully that doesn’t break something else…)


This is a pretty niche solution, but hopefully it is helpful to someone who gets stuck in the same quagmire.

I had the same issue, and it is now fixed.
mix ecto.reset or anything else were absolutely not helping.

Basically what happened, were GenServer I was removing from my supervision tree during tests; but were called anyway during tests, leading to an error that crashed the Repo process.

To fix this, figure out a way to have a GenServer replying or doing the business where it is called (mocking, stubbing, whatever suits your need)