Patreon syncing by connection

Product Support

AI-generated summary

Users Headless and janbolmeson report issues with the Patreon plugin not syncing rewards to Discourse groups, even when emails match and accounts are connected. itsbhanusharma initially suggests email mismatch as the cause, but users confirm emails are identical and verified. JammyDodger asks if emails are verified on Patreon — they are — and checks for console errors, which Headless confirms are absent. janbolmeson shares API error logs showing csrf_detected and runtime check failed (403), hinting at backend sync failures. Falco asks for patron count and admin-level patronage details, revealing some users lack patronage data in Discourse. Headless shares a community member’s theory: auto-renewal must be on for Patreon to consider someone an “active patron.” Falco confirms this aligns with Patreon’s 2016–2019 logic — canceled or non-renewing subscriptions aren’t treated as active, so the plugin won’t grant rewards. The issue appears to stem from Patreon’s definition of “active patron,” not a plugin bug per se, though users feel it’s a critical gap since paying patrons aren’t receiving promised rewards. No fix or workaround is offered beyond ensuring active, auto-renewing subscriptions. janbolmeson and Headless express frustration over lack of support and urgency, given financial implications.

1

I recently installed this plugin and set everything up, for the most part everything works. Users have rewards from the patreon. Most of the users that already shared their discourse email with their patreon email were instantly given their group. However there was a user and maybe more that has their patreon connected to their discourse account via the preferences and don’t share a discourse email with the patreon account. I even refreshed and synced the data and yet they still don’t have the group. Any reasons why this would be happening?

2

If patreon email and discourse email are not the same, the integration will not work. They’ll either need to update their email in discourse or in patreon.

3

What’s the point of connecting then? Just for login purposes?

4

I have the same problem and I have checked and double-checked that emails are the same. Lately I have quite a few users with this problem which I hadn’t earlier. I tried to do a manual sync, but it still doesn’t work.

Is there a way to see a log? (I can provide access to my forum / installation where you can check it)

5

Yeah I had the user make their patreon and discourse email the same, synced up and they still don’t have their rewards

6

are there any updates on why this would be occurring?

7

Please any support? This is a pretty breaking bug especially when people pay for rewards..

8

I’m afraid I’m not very familiar with this plugin. There was an issue recently about email verification. Have these users that aren’t syncing verified their email on the Patreon side of things?

10

Yes, their email is verified on Patreon.

11

Hmm. :thinking:

Are there any errors in the console when you press "Update Patreon Data & Sync Groups”?

12

If you mean inspect element console, then no there are no errors occuring.

13

I have verified several times that emails are the same. I have the problems with multiple users.

Is there a way to see some sync-log or similar?

Only respons I get from “https://xxxxxx/forum/patreon/update_data.json” is:

image
image819×259 7.53 KB

14

Yeah i am unsure what is going on, it does not seem like anyone knows lol.

15

Sorry, it’s not a plugin I’ve used so my trouble-shooting efforts consist of checking for recent changes and searching for similar topics. :slightly_smiling_face: There’s this similar one with a few bits in, but it’s quite old Patreon Plugin Not Updating

It can get quite quiet here on the weekends, but hopefully someone with some experience with it can shed some light soon. :crossed_fingers:

16

Any updates on this?

17

Ping from me as well on this…

18

How many patrons do you have in total?

Can you check for patronage details in the user details admin page?

20

On patreon or on discourse?

The patreon page itself says it has
image

21

For some, but not for the users it doesnt work for.

I also noticed this error today in the error console:

Patreon-API : {"errors":[{"code":1,"code_name":"generic-error","detail":"A runtime check failed.","id":"4462cdbf-XXXX-XXXX-86a4-4ddac9780368","status":"403","title":"A runtime check failed."}]}

bakcktrace

/var/www/discourse/plugins/discourse-patreon/lib/api.rb:15:in `campaign_data'
/var/www/discourse/plugins/discourse-patreon/lib/campaign.rb:13:in `update!'
/var/www/discourse/plugins/discourse-patreon/lib/patron.rb:9:in `update!'
/var/www/discourse/plugins/discourse-patreon/app/jobs/scheduled/patreon_sync_patrons_to_groups.rb:11:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-4.0.0/lib/rails_multisite/connection_management.rb:284:in `with_connection'
rails_multisite-4.0.0/lib/rails_multisite/connection_management.rb:77:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
/var/www/discourse/app/jobs/base.rb:279:in `perform'
mini_scheduler-0.13.0/lib/mini_scheduler/manager.rb:93:in `process_queue'
mini_scheduler-0.13.0/lib/mini_scheduler/manager.rb:37:in `block (2 levels) in initialize'

this is another error I found in error log:

(patreon) Authentication failure! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF detected

with backtrace

omniauth-1.9.1/lib/omniauth/strategy.rb:163:in `log'
omniauth-1.9.1/lib/omniauth/strategy.rb:486:in `fail!'
omniauth-oauth2-1.7.2/lib/omniauth/strategies/oauth2.rb:87:in `callback_phase'
omniauth-1.9.1/lib/omniauth/strategy.rb:238:in `callback_call'
omniauth-1.9.1/lib/omniauth/strategy.rb:189:in `call!'
omniauth-1.9.1/lib/omniauth/strategy.rb:169:in `call'
omniauth-1.9.1/lib/omniauth/strategy.rb:192:in `call!'
omniauth-1.9.1/lib/omniauth/strategy.rb:169:in `call'
omniauth-1.9.1/lib/omniauth/strategy.rb:192:in `call!'
omniauth-1.9.1/lib/omniauth/strategy.rb:169:in `call'
omniauth-1.9.1/lib/omniauth/strategy.rb:192:in `call!'
omniauth-1.9.1/lib/omniauth/strategy.rb:169:in `call'
omniauth-1.9.1/lib/omniauth/strategy.rb:192:in `call!'
omniauth-1.9.1/lib/omniauth/strategy.rb:169:in `call'
omniauth-1.9.1/lib/omniauth/strategy.rb:192:in `call!'
omniauth-1.9.1/lib/omniauth/strategy.rb:169:in `call'
omniauth-1.9.1/lib/omniauth/builder.rb:45:in `call'
/var/www/discourse/lib/middleware/omniauth_bypass_middleware.rb:50:in `call'
rack-2.2.3/lib/rack/tempfile_reaper.rb:15:in `call'
rack-2.2.3/lib/rack/conditional_get.rb:27:in `call'
rack-2.2.3/lib/rack/head.rb:12:in `call'
actionpack-6.1.6.1/lib/action_dispatch/http/permissions_policy.rb:22:in `call'
/var/www/discourse/lib/content_security_policy/middleware.rb:12:in `call'
/var/www/discourse/lib/middleware/anonymous_cache.rb:361:in `call'
/var/www/discourse/config/initializers/008-rack-cors.rb:25:in `call'
rack-2.2.3/lib/rack/session/abstract/id.rb:266:in `context'
rack-2.2.3/lib/rack/session/abstract/id.rb:260:in `call'
actionpack-6.1.6.1/lib/action_dispatch/middleware/cookies.rb:689:in `call'
actionpack-6.1.6.1/lib/action_dispatch/middleware/callbacks.rb:27:in `block in call'
activesupport-6.1.6.1/lib/active_support/callbacks.rb:98:in `run_callbacks'
actionpack-6.1.6.1/lib/action_dispatch/middleware/callbacks.rb:26:in `call'
actionpack-6.1.6.1/lib/action_dispatch/middleware/actionable_exceptions.rb:18:in `call'
actionpack-6.1.6.1/lib/action_dispatch/middleware/debug_exceptions.rb:29:in `call'
actionpack-6.1.6.1/lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
logster-2.10.1/lib/logster/middleware/reporter.rb:43:in `call'
railties-6.1.6.1/lib/rails/rack/logger.rb:37:in `call_app'
railties-6.1.6.1/lib/rails/rack/logger.rb:28:in `call'
/var/www/discourse/config/initializers/100-quiet_logger.rb:23:in `call'
/var/www/discourse/config/initializers/100-silence_logger.rb:31:in `call'
actionpack-6.1.6.1/lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
actionpack-6.1.6.1/lib/action_dispatch/middleware/request_id.rb:26:in `call'
/var/www/discourse/lib/middleware/enforce_hostname.rb:23:in `call'
/var/www/discourse/plugins/communiteq-features/plugin.rb:119:in `call'
rack-2.2.3/lib/rack/method_override.rb:24:in `call'
rack-2.2.3/lib/rack/sendfile.rb:110:in `call'
actionpack-6.1.6.1/lib/action_dispatch/middleware/host_authorization.rb:142:in `call'
rack-mini-profiler-2.3.3/lib/mini_profiler/profiler.rb:249:in `call'
message_bus-4.0.0/lib/message_bus/rack/middleware.rb:60:in `call'
/var/www/discourse/lib/middleware/request_tracker.rb:198:in `call'
rails_multisite-4.0.0/lib/rails_multisite/middleware.rb:26:in `call'
/var/www/discourse/plugins/communiteq-features/plugin.rb:137:in `call'
railties-6.1.6.1/lib/rails/engine.rb:539:in `call'
railties-6.1.6.1/lib/rails/railtie.rb:207:in `public_send'
railties-6.1.6.1/lib/rails/railtie.rb:207:in `method_missing'
rack-2.2.3/lib/rack/urlmap.rb:74:in `block in call'
rack-2.2.3/lib/rack/urlmap.rb:58:in `each'
rack-2.2.3/lib/rack/urlmap.rb:58:in `call'
unicorn-6.1.0/lib/unicorn/http_server.rb:634:in `process_client'
unicorn-6.1.0/lib/unicorn/http_server.rb:739:in `worker_loop'
unicorn-6.1.0/lib/unicorn/http_server.rb:547:in `spawn_missing_workers'
unicorn-6.1.0/lib/unicorn/http_server.rb:143:in `start'
unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.7.0/bin/unicorn:23:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/bin/ruby_executable_hooks:22:in `eval'
/var/www/discourse/vendor/bundle/ruby/2.7.0/bin/ruby_executable_hooks:22:in `<main>'

but it seems strange that it should be an authentication error since I can press the “sync”-button in the admin plugin and get “latest synchronization: just now” and that works.

22

Where are you finding these logs?