A bug was reported where Jobs::ProcessPost fails due to an undefined method cancel_scheduled_job for Jobs::Jobs:Module, reproducible in development but not production. merefield suspected it might relate to a recent commit and suggested adding a leading :: to fix the namespace resolution. david confirmed the issue stems from the discourse-narrative-bot plugin, which inadvertently defines ::Jobs::Jobs, interfering with Ruby’s constant lookup. He verified this by commenting out the offending lines and submitted a PR to resolve the mismatched job module names. The issue is development-only, caused by file path/module name discrepancies. merefield acknowledged the fix and thanked david for the quick response.
during Jobs::ProcessPost
I can recreate on command line:
whereas I can successfully reach it by:
Believe it might be related to this:
https://github.com/discourse/discourse/commit/bf6f8299a781922737fa01c408078f4c090885b6
Contains:
In this context, could it require a leading ::?
Hmm, adding a leading :: would certainly fix it… but it shouldn’t be required 
Given that the call comes from within ::Jobs::ProcessPost, Ruby should work up the tree. First it’ll look for ::Jobs::ProcessPost::Jobs, then ::Jobs::Jobs, then eventually ::Jobs module.
The error you’re seeing suggests that something is defining ::Jobs::Jobs… which is weird! Taking a look on my development instance:
[1] pry(main)> Jobs::Jobs
=> Jobs::Jobs
[2] pry(main)> Jobs::Jobs.constants
=> [:RemapOldBotImages, :GrantBadges]
Looks like these lines in discourse-narrative-bot are causing issues. If I comment them out, it solves the problem.
Good news is that it’s development-only - related to the file paths of the jobs mismatching the names of the modules. Here’s a PR to clean things up:
https://github.com/discourse/discourse/pull/16924
Thanks for the report @merefield
Ah, yes, weird and explains why Production didn’t blow up!
Thanks for speedy response!!