während Jobs::ProcessPost
Ich kann dies auf der Befehlszeile reproduzieren:
während ich es erfolgreich erreichen kann durch:
Glaube, es könnte damit zusammenhängen:
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`
Enthält:
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
Könnte es in diesem Zusammenhang ein führendes :: erfordern?
1 „Gefällt mir“
david
26. Mai 2022 um 11:35
2
Hmm, das Hinzufügen eines führenden :: würde es sicherlich beheben … aber es sollte nicht erforderlich sein
Da der Aufruf von innerhalb von ::Jobs::ProcessPost kommt, sollte Ruby den Baum hinaufgehen. Zuerst sucht es nach ::Jobs::ProcessPost::Jobs, dann nach ::Jobs::Jobs und schließlich nach dem Modul ::Jobs.
Der Fehler, den Sie sehen, deutet darauf hin, dass etwas ::Jobs::Jobs definiert … was seltsam ist! Wenn ich auf meiner Entwicklungsumgebung nachsehe:
[1] pry(main)> Jobs::Jobs
=> Jobs::Jobs
[2] pry(main)> Jobs::Jobs.constants
=> [:RemapOldBotImages, :GrantBadges]
Es sieht so aus, als ob diese Zeilen in discourse-narrative-bot Probleme verursachen. Wenn ich sie auskommentiere, löst das das 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
Die gute Nachricht ist, dass es sich um eine reine Entwicklungsumgebung handelt - es hängt mit den Dateipfaden der Jobs zusammen, die nicht mit den Namen der Module übereinstimmen. Hier ist ein PR, um die Dinge zu bereinigen:
main ← 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
Danke für den Bericht @merefield
4 „Gefällt mir“
Ah, ja, seltsam und erklärt, warum die Produktion nicht explodiert ist!
Vielen Dank für die schnelle Antwort!!
2 „Gefällt mir“
david
27. Mai 2022 um 07:00
4
Dieses Thema wurde nach 17 Stunden automatisch geschlossen. Neue Antworten sind nicht mehr möglich.
