Upgrade Failed - Discourse-Solved plugin

Site went down after upgrade, with this message:

Removing the Discourse-Solved official plugin solved the issue (but would prefer to have it back!)

2 Likes

Hit this issue myself, have temporarily disabled the plugin so that the instance would come back up.

Note that the initial upgrade which caused the outage was via /admin/upgrade :astonished: and necessitated a rebuild via ssh.

1 Like

We also saw the same issue after upgrade today.

Is this fully resolved @vinothkannans

1 Like

I had the same problem and I think we decided it had to do with the locations plugin. See this thread>>>HERE

Locations wasn’t installed on any of the three installations where I’ve investigated this issue.

Disabling solved in all three cases took care of it.

(Solved is an official plugin, whereas locations is third party)

2 Likes

That is very interesting…I will have to test again on my side.

I did some changes yesterday in Solved plugin. But still I’m able to browse both “tests-passed” and “stable” branches in my local dev environment without any issues. @jerry0 or @Stephen can you please share the error you are receiving in the browser console? Also are you in the latest version of Solved plugin?

3 Likes

@vinothkannans Perhaps the reason is this:

https://meta.discourse.org/t/upgrade-error-with-question-and-answer-plugin/111821/3

Plugin authors need only add:

or


Site.preloaded_category_custom_fields << "my_custom_field" if Site.respond_to? :preloaded_category_custom_fields 


In the private, in my case, this allowed us to remove errors, do not know how right I am.

4 Likes

We have two discourse installs and we do not have Locations plugin but do have “solved”.

Disabling the “Solved” plugin on both discourse installations fixed the error but we would really like to have the plugin back and use it.

1 Like

This may not be related to the Locations plugin. A similar error will appear with any plugin where additional fields were used.

Perhaps you should find a third-party plugin that adds an error if used in conjunction with the Solved plugin. And then on the forum point to it. This is necessary so that errors in the plugin are corrected faster. There is not much work. But plugin authors may simply not be aware of this.

Thanks for the pointer. Will try to find the source of error plugin.

1 Like

The fingerprint plugin also needs to be updated - I’m not sure if @udan11 is staff or not.

Removed the plugin (the only other one I had was akismet) and all was well.

3 Likes

Ok…i removed the topic preview plugin and enabled “Solved” plugin and discourse builds fine now.

So, the problem is with non-official plugins at this time.

Thanks for your help. I appreciate it.

2 Likes

To fix this issue I created PRs in both “topic-list-previews” and “locations” plugin. cc @angus

I think this is not related to this topic.

4 Likes

Exact same symptoms as the OP, from the method of upgrade to the 502 in nginx (notable as my instance is fronted by apache). Removing the plugin made the second rebuild work. I presume it’s something with the user bulk queries, versus topics.

If you want to split this off to its own topic, I would not object.

@udan11 can add fixing fingerprint to your list?

3 Likes

Hello Anthony,

I could not reproduce the error you are facing on a new installation of Discourse (v2.3.0.beta5 +91 or stable, v2.2.3 +4) with discourse-fingerprint and discourse-akismet.

Can you please provide more information? What is your installation method and what version of Discourse are you running?

3 Likes

What I’m seeing here is a change in how plugins need to be written – to preload the category custom fields. Is that correct? I’m going to assume that any plugin using category custom fields that don’t
preload will run into this conflict with any plugin that does from what I’m seeing here.

Is there any way to make core more resilient so the site doesn’t just fail without much for error messages? As both a developer and a community owner, I found it frustrating there wasn’t anything in the logs about what happened. It just broke.

We may need to improve this

It should have an error log in /logs URL.

3 Likes