during Jobs::ProcessPost
I can recreate on command line:
whereas I can successfully reach it by:
Believe it might be related to this:
committed 01:28PM - 23 May 22 UTC
Previously, with the default `editing_grace_period`, hotlinked images were pulle… d 5 minutes after a post is created. This delay was added to reduce the chance of automated edits clashing with user edits.
This commit refactors things so that we can pull hotlinked images immediately. URLs are immediately updated in the post's `cooked` HTML. The post's raw markdown is updated later, after the `editing_grace_period`.
This involves a number of behind-the-scenes changes including:
- Schedule Jobs::PullHotlinkedImages immediately after Jobs::ProcessPost. Move scheduling to after the `update_column` call to avoid race conditions
- Move raw changes into a separate job, which is delayed until after the ninja-edit window
- Move disable_if_low_on_disk_space logic into the `pull_hotlinked_images` job
- Move raw-parsing/replacing logic into `InlineUpload` so it can be easily be shared between `UpdateHotlinkedRaw` and `PullUserProfileHotlinkedImages`
Contains:
end
end
# onebox may have added some links, so extract them now
def extract_links(post)
TopicLink.extract_from(post)
QuotedPost.extract_from(post)
end
def enqueue_pull_hotlinked_images(post)
Jobs.cancel_scheduled_job(:pull_hotlinked_images, post_id: post.id)
Jobs.enqueue(:pull_hotlinked_images, post_id: post.id)
end
end
end
In this context, could it require a leading ::?
إعجاب واحد (1)
david
26 مايو 2022، 11:35ص
2
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.
if Rails.env == "development"
# workaround, teach reloader to reload jobs
# if we do not do this then
#
# 1. on reload rails goes and undefines Jobs::Base
# 2. as a side effect this undefines Jobs::BotInput
# 3. we have a post_edited hook that queues a job for bot input
# 4. if you are not running sidekiq in dev every time you save a post it will trigger it
# 5. but the constant can not be autoloaded
Rails.configuration.autoload_paths << File.expand_path('../autoload', __FILE__)
end
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:
discourse:main ← discourse:narritive-bot-autoload
opened 11:34AM - 26 May 22 UTC
These incorrect paths were causing the regular jobs to be loaded in a `Jobs::Job… s` module in development mode, which would cause various weird issues.
https://meta.discourse.org/t/228155
Thanks for the report @merefield
4 إعجابات
Ah, yes, weird and explains why Production didn’t blow up!
Thanks for speedy response!!
إعجابَين (2)
david
27 مايو 2022، 7:00ص
4
This topic was automatically closed after 17 hours. New replies are no longer allowed.
