Sending a Message fails with 500 error

bug
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.

1 Like
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.

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.

1 Like
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.

7

Any ideas @zogstrip?

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
2 Likes
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.

1 Like
10

Ok, here’s the fix :baby_chick:

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

2 Likes
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.

12

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

Ok, lemme have another look.

13

Ok, this time it’s fixed :cow:

https://github.com/discourse/discourse/commit/31e8309f0584d8260bb937b45a055c12b21d381e

1 Like
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?

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:

1 Like
16

It works now. Many thanks.

2 Likes