tjchambers
I am trying to bridge Elixir and Python, and am getting a failure in testing.
** (RuntimeError) unknown worker: agr.__main__.AgrWorker
code: Oban.Testing.with_testing_mode(:inline, fn ->
stacktrace:
(oban 2.21.1) lib/oban/queue/executor.ex:109: Oban.Queue.Executor.resolve_worker/1
(oban 2.21.1) lib/oban/queue/executor.ex:74: Oban.Queue.Executor.call/1
(oban 2.21.1) lib/oban/engines/inline.ex:104: Oban.Engines.Inline.execute_job/2
(oban 2.21.1) lib/oban/engines/inline.ex:37: Oban.Engines.Inline.insert_job/3
(oban 2.21.1) lib/oban/engine.ex:216: anonymous fn/4 in Oban.Engine.insert_job/3
(oban 2.21.1) lib/oban/engine.ex:404: anonymous fn/3 in Oban.Engine.with_span/4
As far as I can tell using code I have deduced my Python worker is “_main_.AgrWorker" however no matter what I put in as a worker name, I get an error in finding the worker on the elixir side when I run my tests. I am running my test inline for a worker (an Elixir module). This elixir module enqueues a job which is for a Python class “AgrWorker”. It “seems” like what is happening is that because the test is “inline” on th Elixir side, the subsequent enqueue expects any subsequent Oban Job to also be in Elixir - i.e. it is looking for the Elixir worker to run.
I am not sure how or why it would be able to know about all of the Python Workers available.
Can anyone help me with why this makes any sense?
Where Next?
Trending in Questions
Other Trending Topics
Latest Oban Threads
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #ai
- #graphql
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
kokolegorille
If You don’t mind I have switched the OP section from Question to Oban.
sorentwo
That’s correct. The inline engine runs jobs immediately, as they are inserted, and it never touches the database. In that case the job is referencing a Python class that’s not available as an Elixir module, and there’s no worker module to load and run.
It wouldn’t. In fact, Oban in Elixir isn’t aware that Oban in Python exists at all. They speak the same “language” via the database schema and pubsub (Bridging Elixir and Python with Oban · Oban Pro), but they can’t interchangeably execute code.
You’ll need to use
manualmode to test enqueuing Python jobs, and ensure they’re inserted into a queue that isn’t ran by your Elixir app. Something like this:The jobs won’t execute during tests, but you can be sure they’re in the bridge queue.
Note that Ecto tests run in a sandbox, essentially a transaction, and whatever is inserted during a test is invisible to all other processes or connections. The only way to test end-to-end is without the sandbox enabled an with manual cleanup steps, which may be worth it eventually, but it’s not where I’d start.