# Upgrading Discourse to Rails 6
**URL:** https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004
**Category:** Development
**Tags:** dev-news
**Created:** [9월 9, 2019, 7:48오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004 "2019-09-09T07:48:58Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@kris.kotlarek](https://meta.discourse.org/u/kris.kotlarek)
#### Post date: [9월 9, 2019, 7:48오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/1 "2019-09-09T07:48:59Z")
Hi Team,
Rails 6.0.0 was released 25 days ago so I think it is a time to update Discourse 🙂 There were a few steps I needed to do to make that work.
1. Fix broken specs
- Add empty method `trigger_transactional_callbacks?` to `lib/mini_sql_multisite_connection.rb`
- `UrlHelper` is loading by default `ActionView::Helpers::UrlHelper` instead of `lib/UrlHelper`. I solved it by adding `::` in front, however, what do you think about changing the name of that class?
- In Rails 5.2.3 MigrationContext accepted one argument, in 6.0.0 additional schema is required
1. Fix depracated methods
- Update\_attributes! replaced with update!
- Content\_type will contain charset, media type should be used instead - [rails/guides/source/upgrading\_ruby\_on\_rails.md at main · rails/rails · GitHub](https://github.com/rails/rails/blob/master/guides/source/upgrading_ruby_on_rails.md#actiondispatchresponsecontent_type-now-returns-the-content-type-header-without-modification)
- Fix warning already initialized constant (TRADITIONAL\_ESCAPED\_CHAR, RFC\_5987\_ESCAPED\_CHAR). Before dropped them I confirmed that values in ActionPack are the same
1. Use classic autoloader as the first step before Zeitwerk
2. Fixed migrations on Rails 6.0.0 - newest rails is not allowing mistake from old migration (you can’t define an already defined column ‘integer’)
I made smoke tests that Discourse work as expected. In addition, I run performance tests to ensure there is no regression (I used default 500 iterations).
| Test | Rails 5.2.3 | Rails 6.0.0 | Percent |
| --- | --- | --- | --- |
| categories-50 | 27 | 24 | 88.89% |
| categories-75 | 31 | 26 | 83.87% |
| categories-90 | 36 | 37 | 102.78% |
| categories-99 | 52 | 50 | 96.15% |
| home-50 | 27 | 26 | 96.30% |
| home-75 | 30 | 28 | 93.33% |
| home-90 | 39 | 38 | 97.44% |
| home-99 | 53 | 55 | 103.77% |
| topic-50 | 35 | 27 | 77.14% |
| topic-75 | 36 | 29 | 80.56% |
| topic-90 | 37 | 39 | 105.41% |
| topic-99 | 56 | 50 | 89.29% |
| categories\_admin-50 | 47 | 47 | 100.00% |
| categories\_admin-75 | 54 | 59 | 109.26% |
| categories\_admin-90 | 64 | 66 | 103.13% |
| categories\_admin-99 | 132 | 116 | 87.88% |
| home\_admin-50 | 47 | 46 | 97.87% |
| home\_admin-75 | 51 | 56 | 109.80% |
| home\_admin-90 | 63 | 64 | 101.59% |
| home\_admin-99 | 110 | 97 | 88.18% |
| topic\_admin-50 | 50 | 49 | 98.00% |
| topic\_admin-75 | 58 | 59 | 101.72% |
| topic\_admin-90 | 65 | 67 | 103.08% |
| topic\_admin-99 | 113 | 86 | 76.11% |
| load\_rails | 2593 | 2618 | 100.96% |
| rss\_kb | 318800 | 287332 | 90.13% |
| pss\_kb | 306913 | 275378 | 89.73% |
| Average | | | 89.31% |
I will create a pull request will all the changes mentioned above. Please let me know if you would like me to adjust anything or made additional tests to ensure everything works as expected.
PR - [DEV: Upgrading Discourse to Rails 6 by KrisKotlarek · Pull Request #8083 · discourse/discourse · GitHub](https://github.com/discourse/discourse/pull/8083)
Cheers
Kris
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [9월 9, 2019, 7:56오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/2 "2019-09-09T07:56:36Z")
This is awesome 🎊
Can you put this in a markdown table with percent change? Cursory look is showing not much has changes which is awesome.
Plugin wise, we have a [rake task](https://github.com/discourse/discourse/blob/cd894b7d17a5d0712facb943229cdb2504818a7f/lib/tasks/plugin.rake#L6-L6) that installs all official plugins, can you run that and ensure the plugin specs pass on Rails 6? (rake plugin:spec should do the trick)
---
### Author:  [@kris.kotlarek](https://meta.discourse.org/u/kris.kotlarek)
#### Post date: [9월 9, 2019, 8:36오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/3 "2019-09-09T08:36:39Z")
I updated the original post to display table. Thank you for pointing me plugins specs. I see that 2 specs failed on Travis, I will take a look and fix them.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [9월 9, 2019, 9:38오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/4 "2019-09-09T09:38:32Z")
There are 2 numbers here that I am finding very interesting:
RSS on 6.0 is almost **10%** better.
Topic (median time) - which is our most common route is **22%** faster.
This is some seriously improved perf, are you able to consistently measure 22% faster on `topic-50`? Can you confirm the actual page is rendering right?
---
### Author:  [@kris.kotlarek](https://meta.discourse.org/u/kris.kotlarek)
#### Post date: [9월 9, 2019, 12:07오후 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/5 "2019-09-09T12:07:20Z")
I run benchmark 3 times and this time, results are less spectacular. My flow is to type `ruby script/bench.rb` in correct branch `master` or `rails6`, hit enter and don’t touch keyboard to not affect results
| | topic-50 | RSS |
| — | — | — | — |
| 5.2.3 | 50 | 322852 |
| 5.2.3 | 50 | 309684 |
| 5.2.3 | 50 | 346376 |
| Average | 50 | 326304 |
| 6.0.0 | 49 | 328844 |
| 6.0.0 | 49 | 321824 |
| 6.0.0 | 49 | 283584 |
| Average | 49 | 311417 |
I also connected my development server to performance database to ensure that topic page looks correct. Screenshot below looks fine to me
---
### Author:  [@kris.kotlarek](https://meta.discourse.org/u/kris.kotlarek)
#### Post date: [9월 10, 2019, 11:00오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/6 "2019-09-10T11:00:02Z")
I would like to get your opinion about one fix.
I downloaded all plugins, however one new spec is failing comparing to master (./plugins/discourse-data-explorer/spec/controllers/queries\_controller\_spec.rb:32)
```plaintext
1) DataExplorer::QueryController when disabled denies every request
Failure/Error: render 'default/empty'
ActionView::Template::Error:
wrong number of arguments (given 2, expected 1)
```
That is fixed in master `rspec-rails` [https://github.com/rspec/rspec-rails/blob/4-0-dev/lib/rspec/rails/view\_rendering.rb](https://github.com/rspec/rspec-rails/blob/4-0-dev/lib/rspec/rails/view_rendering.rb)
by changing
` def self.call(_template)` to `def self.call(_template, _source = nil)`
I can monkey patch rspec-rails with a new file in `lib/freedom_patched/rspec-rails.rb` but wanted to ensure that this is the best approach.
I think that this is the last change which is blocking Rails 6 from being merged.
In addition, I noticed that this spec is broken, however, it is broken on master as well, I can try to fix it (./plugins/discourse-calendar/spec/jobs/update\_holiday\_usernames\_spec.rb:14)
```plaintext
Failure/Error: expect(DiscourseCalendar.users_on_holiday).to eq([post.user.username])
expected: ["bruce1"]
got: []
```
Finally, there are deprecated methods in plugins which I can easily fix tomorrow.
What is you opinon about `rspec-rails`?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [9월 11, 2019, 12:44오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/7 "2019-09-11T00:44:29Z")
Oh my, I guess we monkey patch until rspec-rails 4 is released, can not think of any cleaner fix here.
Or… maybe … use the beta gem for now if everything is working?
---
### Author:  [@kris.kotlarek](https://meta.discourse.org/u/kris.kotlarek)
#### Post date: [9월 11, 2019, 1:00오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/8 "2019-09-11T01:00:51Z")
Got you, let my try install beta tonight and see how it goes. It might be easy and smooth update.
---
### Author:  [@kris.kotlarek](https://meta.discourse.org/u/kris.kotlarek)
#### Post date: [9월 11, 2019, 10:20오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/9 "2019-09-11T10:20:55Z")
I made few additional fixes.
First of all, I found why one spec was failing for me in both `master` and `rails6` branch - [FIX: Freezed time used in update\_holiday\_usernames\_spec.rb should be UTC by KrisKotlarek · Pull Request #3 · discourse/discourse-calendar · GitHub](https://github.com/discourse/discourse-calendar/pull/3)
I also created pull requests for deprecated methods in various plugins:
- [FIX: Remove update\_attributes! which is deprecated in Rails 6.0.0 by KrisKotlarek · Pull Request #8 · discourse/discourse-github · GitHub](https://github.com/discourse/discourse-github/pull/8)
- [FIX: Remove update\_attributes! which is deprecated in Rails 6.0.0 by KrisKotlarek · Pull Request #28 · discourse/discourse-cakeday · GitHub](https://github.com/discourse/discourse-cakeday/pull/28)
- [FIX: Remove update\_attributes! which is deprecated in Rails 6.0.0 by KrisKotlarek · Pull Request #23 · discourse/discourse-translator · GitHub](https://github.com/discourse/discourse-translator/pull/23)
- [FIX: Remove update\_attributes which is deprecated in Rails 6.0.0 by KrisKotlarek · Pull Request #1 · discourse/discourse-user-card-badges · GitHub](https://github.com/discourse/discourse-user-card-badges/pull/1)
- [FIX: Update deprecated methods in Rails 6.0.0 by KrisKotlarek · Pull Request #1 · discourse/discourse-yearly-review · GitHub](https://github.com/discourse/discourse-yearly-review/pull/1) - this one was tricky and I am not 100% sure that this is correct
I rebased latest `master` into `rails6` branch
Finally, I updated `rspec-rails` to version `4.0.0.beta2` and it works fine on my local machine. Travis got some problems, however I see same problems in other pull requests so I don’t think this is correlated to upgrade of `rspec-rails`.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [9월 12, 2019, 12:45오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/10 "2019-09-12T00:45:07Z")
This is now merged 🎊 🎊 🎊
Going to keep a close eye on it today, thanks heaps for this work.
And a big thanks to the Rails team for making this such a pleasant upgrade!!
Will report back on this topic with a few pretty graphs.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [9월 12, 2019, 5:47오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/11 "2019-09-12T05:47:12Z")
Upgrade is looking quite uneventful, which is great. Performance is even and remains incredibly similar.
Memory and CPU look remarkably similar.
My only concern (and something I would like to get to the bottom of) it appears we get “runaway” threads for a few seconds regularly on the web workers.
So somehow, some requests are causing a huge number of threads to be spawned and then go away.
Will continue to investigate this, we need to get backtraces when the number is high, so we can find the culprit.
Given everything else is looking really good I will not be reverting the upgrade.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [9월 12, 2019, 7:36오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/12 "2019-09-12T07:36:59Z")
This should be fixed per:
[https://github.com/discourse/discourse/commit/015051ecafe24975268a4022c40f17978f54890e](https://github.com/discourse/discourse/commit/015051ecafe24975268a4022c40f17978f54890e)
This is a result of new code in Rails 6 that protects access to thread bound variable determining if you can use prepared statements or not.
At Discourse we do not use prepared statements at all, so this patch is not something we need.
See more at:
[https://github.com/rails/rails/pull/36949#issuecomment-530698779](https://github.com/rails/rails/pull/36949#issuecomment-530698779)
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [9월 12, 2019, 10:21오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/13 "2019-09-12T10:21:04Z")
And … confirmed … my fix gets rid of the large amount of thread spikes
Also worth noting… this is how I debugged it:
1. I wrote this little class
```ruby
# frozen_string_literal: true
class Thread
attr_accessor :origin
end
class ThreadDetective
def self.test_thread
Thread.new { sleep 1 }
end
def self.start(max_threads)
@thread ||= Thread.new do
self.new.monitor(max_threads)
end
@trace = TracePoint.new(:thread_begin) do |tp|
Thread.current.origin = Thread.current.inspect
end
@trace.enable
end
def self.stop
@thread&.kill
@thread = nil
@trace&.disable
@trace.stop
end
def monitor(max_threads)
STDERR.puts "Monitoring threads in #{Process.pid}"
while true
threads = Thread.list
if threads.length > max_threads
str = +("-" * 60)
str << "#{threads.length} found in Process #{Process.pid}!\n"
threads.each do |thread|
str << "\n"
if thread.origin
str << thread.origin
else
str << thread.inspect
end
str << "\n"
end
str << ("-" * 60)
STDERR.puts str
end
sleep 1
end
end
end
```
1. I then wired in unicorn [after\_fork](https://github.com/discourse/discourse/blob/082f59842dd2dc20fbe8e8958428b5714174ad3d/config/unicorn.conf.rb#L194-L194) a require of this class and ran `ThreadDetective.start(14)`
2. The class diligently watched every time a thread was created using a `TracePoint` and placed a tiny frame on the thread called `origin` to help me track where it came from. Once a large number of threads were observed it dumped stuff to STDERR. This can be tracked in `/var/www/discourse/logs/unicorn.stderr.log`
Once I knew that 100 threads were all coming from a single spot, it was very easy to isolate the root cause.
---
### Author:  [@eviltrout](https://meta.discourse.org/u/eviltrout)
#### Post date: [9월 12, 2019, 5:13오후 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/14 "2019-09-12T17:13:50Z")
I noticed that I can no longer use `dev.local` as my hostname in development mode in Rails 6, so I’ve added an ENV variable to configure that whitelist:
[https://github.com/discourse/discourse/commit/95a9a544c9a3d9a39a16bf41e6eb2e23d64edb4c](https://github.com/discourse/discourse/commit/95a9a544c9a3d9a39a16bf41e6eb2e23d64edb4c)
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [9월 15, 2019, 10:03오후 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/15 "2019-09-15T22:03:06Z")
We should not need to keep this monkey patch long term cause we just landed a fix in Rails.
[https://github.com/rails/rails/commit/b9cc147241de73c4950700d94ddb0768d36a01da](https://github.com/rails/rails/commit/b9cc147241de73c4950700d94ddb0768d36a01da)
---
### Author:  [@amotl](https://meta.discourse.org/u/amotl)
#### Post date: [1월 7, 2020, 12:27오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/16 "2020-01-07T00:27:59Z")
안녕하세요,
Discourse에 Rails 6을 적용하기 위해 수고해 주셔서 감사합니다. 혹시 이 기능이 Discourse에 언제 반영될 예정인지 조심스럽게 여쭙고 싶습니다. 아니면 이미 2.4.0.beta에 포함되었을까요? 인스턴스에 설치된 플러그인 중 일부가 깨질 수 있는지 가능 여부에 대해 질문드립니다.
감사합니다.
안드레아스 드림.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [1월 7, 2020, 12:34오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/17 "2020-01-07T00:34:56Z")
이 기능은 9월부터 기본 릴리스 채널을 사용하는 모든 사용자에게 제공되고 있습니다. 처음에는 2.4.0.beta5에서 소개되었습니다.
---
### Author:  [@amotl](https://meta.discourse.org/u/amotl)
#### Post date: [1월 7, 2020, 1:38오전 UTC](https://meta.discourse.org/t/upgrading-discourse-to-rails-6/128004/18 "2020-01-07T01:38:59Z")
네, 정말 감사합니다. 2020년에도 좋은 일만 가득하시길 바라며, 여기서 해주시는 모든 일에 감사드립니다.