抱歉，如果这个类别不正确。
我正在评估 Discourse，并且 VersionCheck Job 在我的环境中失败了。
我注意到失败的任务在 Sidekiq 中堆积，并且可能会在默认的 25 次重试后（根据 https://www.rubydoc.info/gems/sidekiq/Sidekiq/JobRetry）被移至“dead”部分。
我知道我需要调查导致它失败的原因，但关键是：将这些任务保留在那里是否有意义？直接丢弃失败的版本检查并等待下一次任务执行不是更好吗？
目前我有超过 80 个 VersionCheck 任务等待重试，对我来说这看起来是资源的浪费（可能很少，但仍然是浪费）……
根据我的检查，在 app/jobs/scheduled/version_check.rb 中添加 sidekiq_options retry: false 就可以解决这个问题。
我是否遗漏了什么？
您是如何安装的？有理由相信您存在网络问题吗？内存？
您可能是对的，但由于到目前为止只有您报告了这个问题，因此它还没有进入优化列表。我认为，在尝试一次后就让它失败是有意义的。
您上次升级是什么时候？
几周前（大约在十月底）版本检查作业出现了一个问题，现在已经解决了。如果您在终端进行升级（./launcher rebuild app），应该就没问题了。
我正在使用标准的 docker 安装在 ec2 实例中。
我处于企业环境中，实例和互联网之间有很多防火墙、代理和安全扫描器。在日志中，我看到一个“Job exception: Connection reset by peer - SSL_connect (Errno::ECONNRESET)”错误，所以很可能某个防火墙在某个时候拒绝了请求……我还在了解 discourse 是如何进行版本检查的，以便手动重现它们并获取更多详细信息。
完全理解。过去我曾使用过 gitlab，并遇到过许多问题，其中 sidekiq 队列过满导致性能下降和其他奇怪的行为，所以每次看到这种情况我的警报都会响起。
我使用的是 2.8.0.beta9 (959923d3cf)
是的……在终端或通过 GUI 升级都可以正常工作（每周运行一次）。在这种情况下唯一的问题是主管理员屏幕没有显示最新版本，并且一直显示我运行的是过时的版本。
那么您绝对应该运行命令行升级。
Discourse 会连接到互联网以执行诸如检查版本升级、获取用户头像、将远程图像下载到本地存储以及常规的 oneboxing 等任务。如果实例与互联网断开连接，确实会发生一些故障。
是的！我每周都在这样做，直到找到解决方案。
我正是因为这个原因才不得不放弃了oneboxing。目前我不能允许该服务器完全访问互联网。
github.com/* 已经被允许，但这个版本检查任务可能使用了另一个 URL 来完成此操作。
我会关闭 SiteSetting.version_checks，移除 discourse_docker 插件并进行命令行升级。
但是，在这里，如果你能打开 https://api.discourse.org/api，那么你可能就没问题了。
谢谢你的信息！当我允许访问 https://api.discourse.org/api/version_check 时，它就成功了。