Can't activate CW subscription, no Suppliers listed in plugin settings


Discourse Version: 2.9beta10

Plugin Commit: FIX: straighten-out wizard-level subscription features · paviliondev/discourse-custom-wizard@12cd8ac · GitHub

Steps to Reproduce

  1. Go to (@angus you guys have admin account)
  2. No supplier listed on our instance

Screenshot 2022-10-28 at 16.29.35



Nothing in forum/browser logs

Strange, haven’t seen this before. It’s possible it’s related to your hosting. I’ll chat with @richard .

The only thing worth mentioning is that every site we host is always a multisite, regardless of the plan.

hm ok. Nothing is standing out to me, and like I said, this is the first I’ve seen this.

@richard Can you think of any reason why this wouldn’t work on your servers?

See also

@richard It performs a request to get “Provider” data here

But any connection errors are stored in the plugin store, and there’s nothing there on JR’s instance.

This suggests to me that it’s not even finding the Custom Wizard plugin, i.e. that find_plugin code isn’t working for some reason.

@Jrgong @richard I’ll add some more logs in there on Monday so we can get a clearer picture as to why it’s not working in this environment.

I can confirm this is a multisite issue. The table in the multisite master database contains the supplier, the table in the other multisite databases do not, so /admin/plugins/subscription-client/suppliers returns an empty json response.

Quick (and dirty!) fix below, but there might be more issues, didn’t test that, it’s late already.

--- a/plugin.rb
+++ b/plugin.rb
@@ -39,7 +39,9 @@ after_initialize do
     load File.expand_path(path, __FILE__)
+    RailsMultisite::ConnectionManagement.each_connection do
       SubscriptionClient::Resources.find_all unless Rails.env.test?
+    end

It occurred to me that it is highly undesirable to execute the find_suppliers function during startup. It introduces a direct dependency to network connectivity and external services, preventing delaying Discourse to start when one of those fail take more time .

Could this be done in an async job that is triggered upon plugin initialization? The additional benefit is that this gives you automatic multisite capabilities since Discourse will trigger a separate job for each individual multisite member.

Thanks, I’ll take a look at this approach on Monday.

It doesn’t prevent startup if the connectivity fails.

Yes, I’ll consider that.

Thanks :+1:

@richard @Jrgong Sorry this has taken so long. I have a new computer and setting up the rspec environment for multisite unit tests proved harder than normal.

@Jrgong once richard reviews this and it’s merged the subscription plugin will work on communiteq’s multisite environment.

Reviewed and found working, going to merge it now, thank you Angus!