No config registered for [Oban, Oban.Met] instance

[Arp-G]

Environment

• Oban Version
• PostgreSQL Version
• Elixir & Erlang/OTP Versions (elixir --version)

Current Behavior

We recently upgraded oban, oban web and oban pro packages. After the upgrade when trying to open the oban dasboard I get the following error no config registered for [Oban, Oban.Met] instance

These were the changes I did during the upgrade

- {:oban, "~> 2.14"},
- {:oban_web, "~> 2.9.6", repo: "oban"},
- {:oban_pro, "~> 0.13", repo: "oban"},

+ {:oban, "~> 2.16"},
+ {:oban_web, "~> 2.10", repo: "oban"},
+ {:oban_pro, "~> 1.1.0", repo: "oban"},

Replaced:

config :connect_pool, Oban,
  engine: Oban.Pro.Queue.SmartEngine,
  repo: Connect.DB.Repo,
  plugins: [
    {Oban.Plugins.Pruner, max_age: 86400},
    Oban.Plugins.Gossip,
    Oban.Web.Plugins.Stats]

with

config :connect_pool, Oban,
  engine: Oban.Pro.Engines.Smart,
  repo: Connect.DB.Repo,
  plugins: [
    {Oban.Plugins.Pruner, max_age: 86400}
  ]

(PS: We have an umbrella app setup)

I read the changelog and went through the hex docs insllation pages, maybe I missed something?
Any idea what configuration I am missing which could lead to this error?

Expected Behavior

Oban web dashboard opens and works as expected

[sorentwo]

Thanks for the report. There's a timing issue exposed in umbrellas when the :oban_met application loads after Oban has already started. I'm not sure yet whether there's an appropriate fix in code or if it only warrants some documentation.
In the meantime, here are a few potential fixes:

1. Ensure oban_met is a dependency of the sub-app where you start Oban and let auto-loading take care of it.
2. Explicitly call Application.ensure_all_started(:oban_met) in your application before starting Oban in your supervision tree.
3. Start an Oban.Met instance explicitly and supervise it in your own application tree with {Oban.Met, conf: Oban.config()}

[Arp-G]

Hi, thanks for the quick response. I tried this

• Added :oban_met under extra_applications in my umbrella apps mix.exs file - This fixed the issue

• I also tried calling Application.ensure_all_started(:oban_met) before starting my supervision tree, this also fixed the issue.

• Start an Oban.Met instance explicitly and supervise it in your own application tree with {Oban.Met, conf: Oban.config()}

Could not make this work, probably I am doing something wrong.

Anyway, I went with the fix of adding :oban_met under extra_applications.
Until we have a fix in the code for this I believe we can add something in the docs.

Once again, thanks for your quick response and maintaining this awesome library 🙏
Feel free to close this issue. Thanks!

[sorentwo]

Thanks for the follow-up @Arp-G. There's a proper fix in :oban_met main now (see the linked issue for the commit message).

[marpo60]

Hi @sorentwo

We faced this issue and the potential fixes didn't solve our issue.

Any estimate when a new release of :oban_met will be cut?

[sorentwo]

@marpo60 This should be fixed in v0.1.3. Which version of oban_met are you using?

[marpo60]

Im running v0.1.3 🤔

Due to app constraints im running multiple Oban instances.

[marpo60]

Sharing an error trace

GenServer {Oban.Registry, {Oban.ABC, Oban.Met.Reporter}} terminating
** (RuntimeError) No Oban instance named `Oban.ABC` is running and config isn't available.

    (oban 2.15.4) lib/oban/registry.ex:37: Oban.Registry.config/1
    (oban 2.15.4) lib/oban/peer.ex:115: Oban.Peer.leader?/2
    (oban_met 0.1.3) lib/oban/met/reporter.ex:89: Oban.Met.Reporter.handle_info/2
    (stdlib 4.0.1) gen_server.erl:1120: :gen_server.try_dispatch/4
    (stdlib 4.0.1) gen_server.erl:1197: :gen_server.handle_msg/6
    (stdlib 4.0.1) proc_lib.erl:240: :proc_lib.init_p_do_apply/3
Last message: :checkpoint

[sorentwo]

That's different than the original issue and seems like a configuration problem more than a bug. The tracker isn't supposed to be used for troubleshooting; will you message me on Slack or the ElixirForum?

[atonse]

@sorentwo I still saw this issue with 0.1.3 (which brought me here). FWIW, it's for this setup:

app1 -> runs only workers
app2 -> umbrella, runs its own workers, runs web instance for app2, and also runs web instance for app1

The web instance for app1 (which runs in the umbrella app2) continued to fail. But once I did the ensure_all_started that fixed it. It might be a crazy edge case but hope that helps.