Oban bringing app down with `expected :repo to implement Ecto.Repo, got: MyApp.Repo` on prod

Phoenix Forum Questions / Help
,
1

Application is encountering an error in prod environment during startup, leading to a crash. The error message suggests a problem with the initialization of the Oban application. Oban is working fine in dev environment

Application myapp exited: MyApp.Application.start(:normal, []) returned an error: shutdown: failed to start child: Oban
    ** (EXIT) an exception was raised:
        ** (ArgumentError) expected :repo to implement Ecto.Repo, got: MyApp.Repo
            (oban 2.17.1) lib/oban/config.ex:91: Oban.Config.new/1
            (oban 2.17.1) lib/oban.ex:387: Oban.start_link/1
            (stdlib 5.1.1) supervisor.erl:420: :supervisor.do_start_child_i/3
            (stdlib 5.1.1) supervisor.erl:406: :supervisor.do_start_child/2
            (stdlib 5.1.1) supervisor.erl:390: anonymous fn/3 in :supervisor.start_children/2
            (stdlib 5.1.1) supervisor.erl:1258: :supervisor.children_map/4
            (stdlib 5.1.1) supervisor.erl:350: :supervisor.init_children/2
            (stdlib 5.1.1) gen_server.erl:962: :gen_server.init_it/2

defmodule MyApp.Repo do
  use Ecto.Repo,
    otp_app: :myapp,
    adapter: Ecto.Adapters.Postgres
end

On futher investigating we found out that Oban uses __info__(:attributes) to check if repo implements Ecto.Repo behaviour and on prod when we ran MyApp.Repo.__info__(:attributes) it return empty list causing above error.

Not sure why __info__(:attributes) is returning empty list of attributes on prod environment. Any help here will be appreciated

2

Hi @nikhilbelchada can you provide information about which version of ecto and Oban you are using?

3

Here are the details

  • Oban Version: 2.17.1
  • PostgreSQL Version: 15.5
  • Elixir & Erlang/OTP Versions (elixir --version): Elixir 1.15.7 & Erlang/OTP 26
  • Ecto: 3.11.1
4

@nikhilbelchada That’s the first time I’ve heard of this issue. The Repo check changed to look at behaviours in Oban v2.17, it only used to check whether a config function was exported.

  1. Is this the first time you’ve deployed Oban to production, or is this after an upgrade?
  2. How do you deploy in production? Are you using releases?
5

Thanks for addressing our query

  1. yes, this is the first time we are using Oban in Production.
  2. We aer using nix(nixOS) to create a release for production. I guess nix is causing this
6

This is due to nix (nixOS) release. We figured out fix through nix.
We can mark this resolved

1 Like
7

Can you check whether other modules have behaviours in production? Oban also checks that a job’s worker implements Oban.Worker in a couple places using behaviours.

8

We chased this down to Nix’s mixRelease option called stripDebug. It’s false by default, but if set to true then MyApp.Repo.__info__(:attributes) comes out empty.

In a way easy not so complex once we know all the moving pieces, but identifying this as the root problem took a while. I guess those warnings in mixRelease aren’t to be ignored.

Oban appears to work fine now. And thanks for your responses @sorentwo and @benwilson512.

3 Likes