Sending a Message fails with 500 error


#1

When trying to send a message to a particular user (or at least not all users) I’m seeing a 500 error.

In the production log I see:

production.log:
Started POST "/posts" for 168.1.6.43 at 2015-09-09 07:35:10 +0000
Processing by PostsController#create as JSON
  Parameters: {"raw"=>"Test junk - McNaughty, and we don't have proper way to get root password, but then decided to walk yet, and then I'll look at it when I have the dimensions of knots and then we should look at logs.", "title"=>"testing", "is_warning"=>"false", "archetype"=>"private_message", "target_usernames"=>"LDC", "typing_duration_msecs"=>"10100", "composer_open_duration_msecs"=>"176608", "nested_post"=>"true"}
Completed 500 Internal Server Error in 142ms (ActiveRecord: 30.6ms)
ArgumentError (comparison of String with 0 failed)
/var/www/discourse/app/models/topic_user.rb:102:in `>='

looking at topic_user.rb, it appears that the error results from the following resulting in a string value in:

      auto_track_after = User.select(:auto_track_topics_after_msecs).find_by(id: user_id).auto_track_topics_after_msecs
      auto_track_after ||= SiteSetting.default_other_auto_track_topics_after_msecs

I’m guessing the problem might stem from a non-numeric character in a setting somewhere, but I’m not sure where to look for it. Any suggestions?

If it is the case that a non numeric value can be entered where a numeric one is required, that probably also will want addressing.


#2

I’ve gotten into the rails console:

root@forum:/var/www/discourse# rails c
[1] pry(main)> User.select(:auto_track_topics_after_msecs).find_by(id: 38).auto_track_topics_after_msecs
=> nil
[2] pry(main)> SiteSetting.default_other_auto_track_topics_after_msecs
=> "0"

So it appears that it’s the Site default setting that is the issue. There’s no non numeric characters in that value, but I am getting a string value where a numeric one is expected.


(Jeff Atwood) #3

What version of Discourse are you on? There was a bug like that with site setting types a week or so ago. Update to latest.


#4

it has been more than a week. will update now.


#5

Actually, it seems my colleague did the internal update process this morning to see if it would help.


#6

I’ve now done a git pull and container rebuild also. It’s no better.


(Jeff Atwood) #7

Any ideas @zogstrip?


(Régis Hanol) #8

Just tried and when you change that setting it saves it as a string instead of an integer. Will fix.

In the meantime, @mc0e, you can fix it by updating the setting to an integer via the rails console

root@forum:/var/www/discourse# rails c
[1] pry(main)> SiteSetting.default_other_auto_track_topics_after_msecs = 0
=> 0

#9

OK, I tried that. It doesn’t stick. e.g. if I do it and then restart the rails console it’s back to how it was before with a string value. Also doesn’t fix the message sending in the site.


(Régis Hanol) #10

Ok, here’s the fix :baby_chick:

https://github.com/discourse/discourse/commit/9a999bfe84b34ce64fa805db10be0f8df4983857


#11

Still get the error in the site, and get a string for SiteSetting.default_other_auto_track_topics_after_msecs:

root@forum:/var/www/discourse# git pull
From https://github.com/discourse/discourse
   5ed7663..9a999bf  tests-passed -> origin/tests-passed
Updating 5ed7663..9a999bf
Fast-forward
 config/locales/server.en.yml                   |  4 ++--
 lib/site_setting_extension.rb                  | 23 +++++++++--------------
 lib/site_settings/db_provider.rb               |  8 ++------
 lib/site_settings/local_process_provider.rb    |  2 +-
 spec/components/site_setting_extension_spec.rb | 13 +++----------
 5 files changed, 17 insertions(+), 33 deletions(-)
root@forum:/var/www/discourse# rails c
[1] pry(main)> SiteSetting.default_other_auto_track_topics_after_msecs
=> "0"
[2] pry(main)> SiteSetting.default_other_auto_track_topics_after_msecs =0
=> 0
[3] pry(main)> 
root@forum:/var/www/discourse# rails c
[1] pry(main)> SiteSetting.default_other_auto_track_topics_after_msecs
=> "0"

Oddly a git pull and container rebuild didn’t seem to pick up the new source, hence the git pull from within the container.

I tried changing the setting through the web gui also, and I still get a string value.


(Régis Hanol) #12

Probably because you didn’t for the build to push the commit to the test-passed branch.

Ok, lemme have another look.


(Régis Hanol) #13

Ok, this time it’s fixed :cow:


#14

Is the CI process documented somewhere?

What’s the schedule for moving stuff into tests-passed? IS there a CI testing and integration process that kicks off when the commit is entered into master, or is it periodic? How long does it generally take?


(Régis Hanol) #15

It usually takes about 10 minutes for a commit to be moved from master to test-passed, unless the build is broken… Which I’m fixing is fixed now :wink:


#16

It works now. Many thanks.


(Régis Hanol) #17