User Messages Inbox Error 500

Mhm this sounds like giving it a shot.

Thinking about localization I was wondering if the behavior should change, by changing users interface setttings? Any thoughts on that?

I will try the deletion solution in the next few days.

Thanks for your help.

I the meantime we thought around a bit. Maybe anyone else has some input to share.

An other strange thing is, the in the messeage pane area, by clinking on the user icon and the clicking the envelope. There should be displayed all recent messages, right? In the case of our users that is not able to open the inbox there is just nothing?

Maybe someone has some ideas on that. When we can for sure say that there sould be listed some entries.

no_messages

Maybe this will point some ideas in any direction?

And some other route of thinking. We still have some kind off ssl error on our site. As I said, running discourse with docker on a reverse proxy on apache. But the domain has its working ssl cert by lets encrypt.

Still we have some mixed content warnings on the site. By any means the standard logos and favicons are served by http. We deleted the custom brandings in behalf of getting rid of the mixed content errors.

So is there any chance that this might cause the problem?

When we recently hit the JSON route `https://sub.domain.de/topics/private-messages/firstnamename.json

The JSON result is

{
	"status":500,
	"error":"Internal Server Error"
}

I closer look into logs brought up this

NoMethodError (undefined method `downcase' for nil:NilClass)
app/models/global_setting.rb:107:in `s3_bucket_name'
app/models/site_setting.rb:157:in `absolute_base_url'
app/models/upload.rb:184:in `secure_media_url_from_upload_url'
lib/url_helper.rb:60:in `secure_proxy_without_cdn'
lib/url_helper.rb:90:in `cook_url'
app/models/topic.rb:126:in `image_url'
app/serializers/listable_topic_serializer.rb:34:in `image_url'
(eval):10:in `_fast_attributes'
lib/freedom_patches/ams_include_without_root.rb:57:in `include!'
app/controllers/application_controller.rb:454:in `serialize_data'
app/controllers/application_controller.rb:463:in `render_serialized'
lib/topic_list_responder.rb:16:in `block (2 levels) in respond_with_list'
lib/topic_list_responder.rb:9:in `respond_with_list'
app/controllers/list_controller.rb:177:in `message_route'
app/controllers/list_controller.rb:164:in `block in generate_message_route'
app/controllers/application_controller.rb:354:in `block in with_resolved_locale'
app/controllers/application_controller.rb:354:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:354:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'

As we are not using secure media and no s3 either I still stumble over these entries:

app/models/site_setting.rb:157:in `absolute_base_url'
app/models/upload.rb:184:in `secure_media_url_from_upload_url'
lib/url_helper.rb:60:in `secure_proxy_without_cdn'

So any chance that this might be cause by a mixed content error under the hood?

Thanks for still haning in there.

1 Like

This is only called on secure uploads. My guess is that in the past you had it configured and since you have removed this.

https://github.com/discourse/discourse/blob/0567eb16fe5065601ea691977339cdf776b8d4e3/lib/url_helper.rb#L90-L90

What does this return?

./launcher enter app
rails c
> Upload.where('secure').count

cc @martin

(also we have a naming bug on site_setting.rb:157:in absolute_base_url' It should be called s3_absolute_base_url )

1 Like

Hey Sam,

thank you very much for taking a look into that!

Well as far as I know we did not activate the secure upload feature. But as fas as I am not the only admin I can not be sure about that. And if I am getting it right, your count should return 0 when the feature has never been activated? Well, it is a lot more than 0 :wink: 235 in fact :blush:

This returns

[1] pry(main)> Upload.where('secure').count
=> 235
[2] pry(main)> 

Is there anything I can do to fix that?

Should I deactivate the seucure media allow embeded images in emails setting?

Is it worth to try ti activate secure media and then to deactivate that?

Thank you so much for trying to help out here!

1 Like

If you do not currently have secure media enabled you don’t need to enable it. It must have been enabled at some point because of how many secure uploads you have. Try running the uploads:secure_upload_analyse_and_update rake task; this will go through all your uploads and mark them as secure/not secure based on site settings (if you have secure media disabled they will all be marked as not secure).

4 Likes

Hey Martin,

thanks a lot. I will give this a try tonight.

Just to get you right. We have currently activated

Should we toggle this option too? Or does this not affect the marking process?

And just to be clear, after the rake command, do I habe to rebuild app? Or is this not necessary, but maybe recommended?

Thanks so much!

This option is enabled by default, but it does nothing unless secure media is enabled.

I don’t think a rebuild is necessary, I have run this on live sites with no problems.

1 Like

Thank you so much!

I give it a shot and will report tomorrow.

THX THX!

1 Like

I’m guessing, but the backtrace looks like it’s trying to serialise a list of messages, or a list of information from messages, and is failing when it comes to serialise a particular image. The image is presumably the profile image of a user. Only one account is affected, so perhaps the bad image is for a user who only communicated with this affected account.

Possibly the failing list construction is for the most recent N messages. Perhaps you could send N messages (with different topic titles) to the afflicted account, so the list only contains good messages?

4 Likes

Martin thanks again for the tip.

Well I tried to run rake uploads:secure_upload_analyse_and_update but the output was

This task only works for external storage.

So I tried to active the activate secure media option. But unfortunately or lets say for the sake of avoiding admin errors. This option can only be activated by configuring Amazon S3 buckets. And I am absolutely sure that no one ever made a S3 setup before.

So I can not run the rake script because I do not have any S3 Storage available. So I can’t say if it has an effect on the pry(main)> Upload.where('secure').count

I am wondering why we still have some secure uploads when we never had S3 activated?

Any clues on that.

But in fact

Did the trick. So I am fine for now. Even if I have no clue why we are experiencing such behavior. I would be happy to learn what else could be the reason.

Thanks in advance and for all your time you already spent.

Well Ed_S what can I say besides

THANK YOU SO MUCH

In fact your little hint did the trick. I just wrote one new message and posted another answer and then the error disappeared.

Even being my hero for the moment does not free you from further questions :wink: I hope you are OK with giving me some more understanding of what in hell happened here.

First of all to give me a better understanding of how to read the logs. I mean, what a great guess you made. What did you lead to think about a serialization problem might be the one breaking it?

lib/url_helper.rb:90:in `cook_url'
app/models/topic.rb:126:in `image_url'
app/serializers/listable_topic_serializer.rb:34:in `image_url'

Why not the cook_url or I do not know, anything else?

Secondly what are your consumptions, do I have to be aware of running in such a problem again? Or maybe with another user?

Do you think there is a way to narrow it down which message, user, image could be the bad guy here. Is there any other chance to take a look into that than … clicking through the messages and hoping to get a effect on one of the private messages posts?

The funny thing is that some admins just did the exact same thing, like writing a new message (topic) to the affected account and we did experience any other behavior. Somehow the last sent message from me to the affected account did the trick.

And the last one, can I have your phone number for further emergency shout outs? Just kidding! :wink:

But for real, thanks a lot, a lot lot, a lot lot lot. I really got stuck here an I am so glad that our user – as I mentioned, one of our admins – can get back on track. Thank you Ed_S!

2 Likes

:clap:
Very nice guess !

1 Like

Ha ha - seems like I got lucky. The thing about a stack trace is that it runs from the specific to the general - it’s not just a list of things, but a picture of the nested interactions from general code down to the specific machinery. So, the ‘image’ idea seemed interesting, because there are only profile images in the message list. And I think we’ve seen odd issues with profile images before.

But I have no idea why the code is looking at secure storage, if you’ve never used it.

I suspect a database query could list the images which would be fetched in this case, but I don’t know how you might find the rogue profile. If indeed, this is the story behind the stack trace.

2 Likes

There is a rake task to fix this:

./launcher enter app
rake uploads:secure_upload_analyse_and_update

I recommend you run that.

1 Like

Hey Sam,

thank you very much for still having this on your list. I am really happy to get further assistance to get this right.

Well I tried

But in fact the same output was fired, that this only works für external S3 storages and as long as we do not habe one setup, I a little lost here.

Here my console:

./launcher enter app
rake uploads:secure_upload_analyse_and_update
This task only works for external storage.

Am I missing something? Or is this a bug and it should run with secure media switched off?

Thanks for your expertise.

1 Like

Well in fact it is luck what keeps us alive sometimes, right?

Still thank you, I really got a little frustrated and deleting all messages was really just a last option.

Well, maybe you can give me some hint on to topics here. For me, being relatively new to docker and discourse I am a litte lost by your suggestion to fire a db query. What DB is used by discourse and can I do something like

./launcher enter app 
mysql select bla

Or is it mongo db? But entering an fireing the query inside the container is at least the right way to go, isn’t it?

And is there a list of fields or properties I can browse through, like a reference or something so that I could bring up some thoughts about the right query?

But just to get this clear, even if I manage to get the list of profile images in the inbox list – there is still no suggestion for narrow it down which one would be the bad guy or what to do with even if we find it, right? Any thoughts on that maybe?

Moreover I am surprised that there are usual problems with profile images. Is there a specific topic I could read through to get more insights on that? Or maybe some kind of guide how to handle profile images or restrict the usage or something? On behalf of avoiding such problems?

Ed_S thank you very much for staying with me.

I don’t know much about the database side, but I recommend the Data Explorer plugin which is an officially supported plugin, and this topic. (Best to start a new topic if you have new questions - others may benefit from the thread, and a suitable topic title will bring more help.)

Edit: perhaps see also

where there are hints of what the mechanism looks like and how you might query it.

1 Like

Hey Ed_S,

thank you very much for the hints. The Data Explorer plugin is awesome! For further analysis it is a real good place to start!

Also the hint with the lost avatars was helpful. I checked it up and it seemed ok. So thanks a lot for sharing the insight.

Well as far as it works for the moment I am very happy. I cross my fingers that it will last :wink:
Thanks again Ed_S for the sustaining help.

If anyone else stumbles upon such error, please let me know what you experienced of what could be done to prevent such errors.

To all thanks for reading.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.