Possible memory leak on Stripe::StripeObject

[VictorPS]

Describe the bug

I am investigating a memory leak in one of the systems I own and I think it is coming from Stripe::StripeObject.

To Reproduce

I was able to run some tests using the Stripe gem and Faraday gem on a separate instance and these were the results:

From 2:15pm until 2:35pm I was making requests to an endpoint that uses the Stripe gem and from 2:35 onwards it was using Faraday.
As you can see, the memory increases linearly when using the Stripe gem, but stays almost constant using Faraday.

This was the code using Rails + Grape:

CUSTOMER_ID = "cus_" # Use an existing customer id

desc "Check if the memory leak is in Stripe::Customer.retrieve"
get '/1' do
  customer = Stripe::Customer.retrieve(CUSTOMER_ID, api_key: ENV["STRIPE_API_KEY"])

  { customer: { id: customer.id } }
end

desc "Use Faraday to see if the memory leak still persists"
get '/2' do
  response = Faraday.get("https://api.stripe.com/v1/customers/#{CUSTOMER_ID}") do |request|
    request.headers['Authorization'] = "Bearer #{ENV["STRIPE_API_KEY"]}"
    # Use the same API version defined in the Stripe gem
    request.headers['Stripe-Version'] = Stripe.api_version
  end

  response_body = JSON.parse(response.body)

  { customer: { id: response_body['id'] } }
end

Then I created a script to hit the endpoints 5000 times each with a delay in between to make it easier to identify in the graphs.

Expected behavior

I would expect the memory to stay constant or be freed on a garbage collection.

Code snippets

No response

OS

Aws Linux 2 and Ubuntu 24

Language version

Ruby 3.3.3

Library version

stripe-ruby v11.7.0 and 13.1.0

API version

2024-04-10

Additional context

My guess is that it is related to Stripe::StripeObject#add_accessors method, I think the dynamic methods are not being garbage collected when the object is destroyed.

This seems to have been going on for a little while (maybe years?), we only noticed a few months ago once we started getting a bit more traffic in one of our services.

[helenye-stripe]

Hi! Thanks for bringing this to our attention - we'll investigate this further, this is certainly not ideal.

[helenye-stripe]

Hi, @VictorPS, so sorry for the delays here. I've looked into this using various memory profiling tools, and I do not believe there is a leak from what I've tested (using a similar example to yours above), i.e. I believe there are no hanging references that prevent these accessors from being garbage collected with their associated objects. However, the SDK does have a much larger memory footprint in general than the more barebones Faraday use above, which may be causing issues.

Do you mind trying to force GC in the script and seeing if the relevant objects are destroyed? That may point to requiring GC tuning. I did observe that GC was not running as frequently as I would have liked given our library's size and number of objects.

[VictorPS]

Hi @helenye-stripe,
I've tried to add GC.start to the Stripe endpoint but it didn't change the outcome:

5.000 requests with GC.start:

Someone from our team had removed newrelic_rpm and newrelic-infinite_tracing gems while switching our logger and that seems to have fixed the memory leak 🎉

5.000 requests with GC.start, without the NewRelic gems:

---

It is very likely that one of these gems are injecting the Stripe requests to track something that is preventing the Stripe objects from being garbage collected.

I am going to continue the investigation on my side to try to pinpoint what the issue was, but we have decided to remove the gems for now as a long term solution.

Feel free to close this issue and thanks for helping with the investigation!

[VictorPS]

I also disabled the httpx instrumentation after reading this issue in the NewRelic repo, newrelic/newrelic-ruby-agent#2386 , which also fixes the memory leak:

  instrumentation:
    httpx: false

So the issue wasn't on the Stripe gem, but on NewRelic's.