# Failed VersionCheck Jobs behavior
**URL:** https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067
**Category:** Development
**Created:** [December 4, 2021, 12:03am UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067 "2021-12-04T00:03:00Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@Bruno\_Salazar](https://meta.discourse.org/u/Bruno_Salazar)
#### Post date: [December 4, 2021, 12:03am UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/1 "2021-12-04T00:03:00Z")
Sorry if this is not the correct category for this.
I’m evaluating discourse and the VersionCheck Job is failling in my environment.
I’ve noticed that failed jobs are piling up inside sidekiq and probably will get moved to the “dead” section after the default 25 retries (as per [RubyDoc.info: Class: Sidekiq::JobRetry – Documentation for sidekiq (8.1.6) – RubyDoc.info](https://www.rubydoc.info/gems/sidekiq/Sidekiq/JobRetry)).
I know that I need to investigate what is causing it to fail, but the point here is: Does it make sense to maintain these jobs there? Isn’t best to simply discard failed version checks and wait the next job execution?
At this moment I have more than 80 VersionCheck jobs waiting for retry and to me it looks like a waste of resources (probably little, but still a waste)…
From what I’ve checked, adding `sidekiq_options retry: false` to [app/jobs/scheduled/version\_check.rb](https://github.com/discourse/discourse/blob/1472e47aae5bfdfb6fd9abfe89beb186c751f514/app/jobs/scheduled/version_check.rb) would solve this.
Am I missing something?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [December 4, 2021, 11:28am UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/2 "2021-12-04T11:28:50Z")
> [@Bruno\_Salazar](#):
>
> I know that I need to investigate what is causing it to fail
How did you install? Is there reason to believe you have network issues? Ram?
> [@Bruno\_Salazar](#):
>
> it looks like a waste of resources (probably little, but still a waste)…
You may be right, but since you’re the only person to report this (at least so far) it’s not made it on the list of optimizations. It does make sense to just let it fail after one try,I’d think.
---
### Author:  [@Steven](https://meta.discourse.org/u/Steven)
#### Post date: [December 5, 2021, 1:14pm UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/3 "2021-12-05T13:14:27Z")
When was the last time you upgraded?
There was an issue with the version check job a few weeks ago (around end of october), it is fixed now. If you upgrade in the terminal (./launcher rebuild app), it should be ok.
---
### Author:  [@Bruno\_Salazar](https://meta.discourse.org/u/Bruno_Salazar)
#### Post date: [December 6, 2021, 1:12pm UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/4 "2021-12-06T13:12:45Z")
> [@pfaffman](#):
>
> How did you install?
I’m using the standard docker install inside an ec2 instance.
> [@pfaffman](#):
>
> Is there reason to believe you have network issues? Ram?
I’m in a corporate environment, so there are lots of firewall, proxies and security scanners between the instance and the internet. In the logs I see a “Job exception: Connection reset by peer - SSL\_connect (Errno::ECONNRESET)” error, so probably some firewall is denying the request at some point… I’m still understandig how discourse does this version checks so I can reproduce them by hand and get more details.
> [@pfaffman](#):
>
> You may be right, but since you’re the only person to report this (at least so far) it’s not made it on the list of optimizations. It does make sense to just let it fail after one try,I’d think.
Totally understand this. In the past I’ve worked with gitlab and seen lots of issues where full sidekiq queues caused performance degradation and other weird behaviours so everytime I see something like this my alarms ring. 😄
---
### Author:  [@Bruno\_Salazar](https://meta.discourse.org/u/Bruno_Salazar)
#### Post date: [December 6, 2021, 1:24pm UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/6 "2021-12-06T13:24:02Z")
> [@Steven](#):
>
> When was the last time you upgraded?
I’m on 2.8.0.beta9 ([959923d3cf](https://github.com/discourse/discourse/commits/959923d3cf0d058630ef4c84070eddbf32a1161b))
> [@Steven](#):
>
> If you upgrade in the terminal (./launcher rebuild app), it should be ok.
Yeah… The upgrade in the terminal or via GUI is working OK (runing it on a weekly basis). The only issue in this case is that the main administrator screen doesn’t show the latest version and always says that i’m running an outdated version.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [December 6, 2021, 6:14pm UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/7 "2021-12-06T18:14:59Z")
> [@Bruno\_Salazar](#):
>
> the main administrator screen doesn’t show the latest version and always says that i’m running an outdated version.
Then you should definitely run a command line upgrade
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [December 6, 2021, 8:09pm UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/8 "2021-12-06T20:09:02Z")
> [@Bruno\_Salazar](#):
>
> I’m in a corporate environment, so there are lots of firewall, proxies and security scanners between the instance and the internet.
Discourse will reach out to the internet for tasks like checking version upgrades, fetching user avatars, downloading remote images to local storage, and general oneboxing. If the instance is severed from the internet, there will be some breakage indeed.
---
### Author:  [@Bruno\_Salazar](https://meta.discourse.org/u/Bruno_Salazar)
#### Post date: [December 6, 2021, 8:21pm UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/9 "2021-12-06T20:21:54Z")
> [@pfaffman](#):
>
> Then you should definitely run a command line upgrade
Yes! I’m doing it every week until I find a solution.
> [@Falco](#):
>
> If the instance is severed from the internet, there will be some breakage indeed.
I had to give up on oneboxing exactly for this reason. For now I can’t allow full internet access for this server.
[github.com/\*](http://github.com/*) is already allowed, but probably this versioncheck job uses another URL to do this.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [December 6, 2021, 8:40pm UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/10 "2021-12-06T20:40:50Z")
> [@Bruno\_Salazar](#):
>
> Yes! I’m doing it every week until I find a solution.
What I’d do is just turn off `SiteSetting.version_checks`, remove the `discourse_docker` plugin and do command line upgrades.
But, here, if you can open up `https://api.discourse.org/api`, then you’re probably good.
>
---
### Author:  [@Bruno\_Salazar](https://meta.discourse.org/u/Bruno_Salazar)
#### Post date: [December 8, 2021, 3:10pm UTC](https://meta.discourse.org/t/failed-versioncheck-jobs-behavior/211067/11 "2021-12-08T15:10:29Z")
> [@pfaffman](#):
>
> But, here, if you can open up `https://api.discourse.org/api` , then you’re probably good.
Thank you for the info! It worked when I allowed access to `https://api.discourse.org/api/version_check`