Datadog tracing support (or maybe entra middleware?)

[HoneyryderChuck]

I'll fill this one as if it were a bug, as I think that the gem should allow some level of tracing on the client.

I'd like to send stripe connection metrics to datadog. The easiest way to do it would be to use dd-trace's integrationw with faraday, however that requires me to add their custom middleware to the faraday builder, and afai've seen, stripe client doesn't allow me to do it. Could this be a feature worth supporting?

[ob-stripe]

Hi @HoneyryderChuck.

Have you checked https://github.com/stripe/stripe-ruby#configuring-a-client? You can pass a custom Faraday object to StripeClient in that way, I think that should allow you to use ddtrace.

To be completely honest though, we're considering removing the dependency on Faraday in a future major version. The library has its own support for logging requests and responses though: https://github.com/stripe/stripe-ruby#logging. Would that cover your use case?

[HoneyryderChuck]

Hi @ob-stripe

Thx for the reply. Yes, I've seen how to configure the client myself, however I'd like not only to add functionality to the existing one (it's mostly fine). I could copy paste it though, but then I'd have to re-set the default connection, and there is no setter for default_conn. The app I work with uses the default connection.

Can I ask why you're considering removing Faraday? I ask because I've recently added a Faraday adapter to httpx, my http client library, with the specific purpose of interfacing with the stripe api over HTTP/2. Any obvious disadvantages I should look at?

[brandur-stripe]

Can I ask why you're considering removing Faraday? I ask because I've recently added a Faraday adapter to httpx, my http client library, with the specific purpose of interfacing with the stripe api over HTTP/2. Any obvious disadvantages I should look at?

There isn't any particular glaring issue with it, but it's caused us various problems over the years, and hasn't brought any significant upside to the table.

For example:

• Faraday strips integer-indexed maps for query strings (any GET requests like upcoming invoices) #608 where Faraday unencodes encoded parameters you pass to it, and then strips them of important data before re-encoding them.
• "Invalid hash" when trying to upload a file #742 resulting from fairly non-obvious code in how file uploads are handled.
• Net::HTTP::Persistent::Error too many connection resets #780 retry problem resulting from use of Net::HTTP::Persistent adapter.

We've developed workarounds for the various problems that we've run into, but the premise of using Faraday was to bring a powerful pluggable client to the table, and it hasn't really made good on that. Instead, we've gotten subtle problems that are hard to debug because the Faraday code isn't particularly easy to follow, and we've had to resort to semi-maintained libraries to get features that you'd hope would be easily accessible like persistent connections.

There's also an argument to be made that fewer dependencies are better (avoids issues with transitive dependencies like in #704), and honestly I think overall it result in simpler stripe-ruby code too.

[frewsxcv]

For those wanting Datadog tracing integration with stripe-ruby, this might be of use to you: https://gist.github.com/frewsxcv/d3ebe3b174059d8cc7b612fc02ebe4fb