Shared hook compilation failure about oban HOT 5 CLOSED

Ok. On CI it would still have progressive compilation. I believe what's happening is that when the old version of the module initializes. I'm investigating and trying to recreate the problem still.

from oban.

The issue was that there wasn't a compilation dependency between the hooks and the worker, but the worker tried verifying hook modules during compilation. It's fixed for the next release.

from oban.

I don't believe an Oban module should use ensure_compiled!, since that can interfere with module compilation order and possibly cause deadlocks. However, something funny is happening here, and we'll get to the bottom of it.

I'm curious, is shared_hook really the module name? It's not a standard-looking module like MyApp.SharedHook?

from oban.

One other thing—is this happening in dev with code reloading, or from running a standalone mix compile?

from oban.

@sorentwo the module name is a standard-looking name like MyApp.SharedHook.
Indeed, something is funny happening here. In the beginning, I was looking into a different solution to this issue by trying to:

• Ensure the file permission is correct
• Rename the module
• Place the module somewhere else in the app
• Remove the explicit hooks attribute and use the implicit way for each module that is supposed to use the shared hook, which works but requires undesirable code duplication.

One other thing—is this happening in dev with code reloading, or from running a standalone mix compile?

It happens in both scenarios and sometimes randomly on GitHub CI which runs:

• mix deps.get
• mix deps.compile

Another weird fix that I forgot to mention on dev with code reloading is if I remove the hooks attribute and then start the server (Phoneix framework), then my app works without the compilation error. After that, I re-add the hooks attribute and start the server which runs without the compilation error.

from oban.