Problem with 500 error with subscriptions

Support
1

This looks like a Bug, but I don’t know what’s going on.

A bunch of users get a 500 error trying to load /s/user/subscriptions/ (when visiting /my/billing/subscriptions.

NoMethodError (undefined method `[]' for nil) app/controllers/application_controller.rb:427:in `block in with_resolved_locale' app/controllers/application_controller.rb:427:in `with_resolved_locale' l



NoMethodError (undefined method `[]' for nil)
app/controllers/application_controller.rb:427:in `block in with_resolved_locale'
app/controllers/application_controller.rb:427:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:35:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:410:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
lib/middleware/default_headers.rb:13:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/processing_request.rb:12:in `call'
lib/middleware/request_tracker.rb:385:in `call'

I was hoping that it was somehow a fluke, as it seems not to be broken for all users. I can’t find a pattern, though.

I can do this:

 user=User.find_by_username 'xxx'
 DiscourseSubscriptions::Customer.find_by(user_id: user.id)

and that works.

I am not sure where to look next.

1 Like
4

Maybe I’m missing something, but /s/<username>/subscriptions/ isn’t a route in the plugin is it?

So far when I visit /my/billing/subscriptions locally and on a production site it redirect correctly to /u/<username>/billing/subscriptions and I’m not getting a 500 error.

Any other clues on how I can repro this?

5

Thanks for you help!

It pulls from that endpoint. And on this server, with some users, I get a 500 error (I should have included a screenshot, I think). I think it’s been happening for a while? They got me on board to upgrade, which I did, and then they reported this error, but it seems that they were hoping that the upgrade was going to resolve it (at least the upgrade didn’t break it?).

Zero. My best guess is that something happened at some point in the past and now it’s getting a nil from somewhere instead of an array? But I’ve looked at the code and don’t see anywhere that’s not testing for nil before accessing an array.

1 Like
6

I’m assuming it’s only for this one site? You aren’t seeing this on other sites? Yes, there is a “bug” where we shouldn’t return a 500, but there is likely some “bad” data somewhere like a missing plan or something. Maybe it got removed in stripe and never got updated in the plugin db.

Can you run these rails console commands to help me debug?

Stripe.api_key = SiteSetting.discourse_subscriptions_secret_key
user = User.find_by(username: 'xxx')
customer = DiscourseSubscriptions::Customer.find_by(user_id: user.id)
subs = ::Stripe::Subscription.list(customer: stripe_customer_id, status: 'all')[:data]
subs.count # note how many subscriptions they have
subscription = subs.first # change this and run the below lines for each sub
price_id = subscription[:items][:data].first[:price][:id]
plans = ::Stripe::Price.list(expand: ['data.product'], limit: 100)
plan = plans[:data].find { |p| p[:id] == price_id }
plan

I’m thinking either plans or plan will return nil, but that will help us narrow down where the issue is. Could you let me know how many subscriptions they have and if there are any missing plans for them?

Likely a code fix I’ll make is to just not return any subscriptions for these users if there is an error, but if they actually have a subscription that isn’t really solving the issue. Maybe I’ll have it return an error that says something like a subscription has been found but there is an error loading the plan details for it, please reach out to an admin for help.

7

Cool. Thanks!

There was one subscription.

One fix on your code:

subs = ::Stripe::Subscription.list(customer: customer.stripe_customer_id, status: 'all')[:data]

There are 100 plans (so probably more than that)-- maybe this is the problem? (I tried with limit: 1000 but that didn’t change anything; I guess that’s a Stripe API limit?)

So maybe if there are >100 plans it fails? Oh, and the users for whom it’s not failing, are on plans that are in the first 100.

discourse(prod)> plan = plans[:data].find { |p| p[:id] == price_id }
discourse(prod)>
=> nil

EDIT:

Yes. If I do this:

# Get the last item's ID
last_price_id = plans.data.last.id

# Get the next 100
next_plans = ::Stripe::Price.list(
  expand: ['data.product'],
  limit: 100,
  starting_after: last_price_id
)

then

discourse(prod)> next_plans[:data].find { |p| p[:id] == price_id }

finds what it’s looking for.

EDIT AGAIN: next_plans.count == 8. I suggested that they delete 10 plans.

1 Like
8

Thanks for all the info, this is helpful.

Ya that would do the trick for a non-code fix. Sounds good if they have a lot of stale plans.

I’ll add some pagination too so that we can grab them all incase we run into this again.

1 Like
9

Here is the fix for that:

1 Like
10

This topic was automatically closed after 4 days. New replies are no longer allowed.