chore: capture sentry backtraces#2166
Conversation
(we were missing the "capture" feature) and switch back to sentry's now longstanding default transport of reqwest+rustls, which avoids issues w/ our grpc client's included boringssl that occurred w/ reqwest+native-tls Closes STOR-493
taddes
left a comment
taddes
left a comment
There was a problem hiding this comment.
lgtm, though I'll have to get brief context on this from you sometime. grpcio ftw. Is this basically where reqwest and grpcio's boringssl fight over TLS internals, so libcurl was used as a side-step since it has its own independent TLS stack that didn't clash?
| // likely grpcio's boringssl | ||
| let curl_transport_factory = |options: &sentry::ClientOptions| { | ||
| Arc::new(sentry::transports::CurlHttpTransport::new(options)) as Arc<dyn sentry::Transport> | ||
| }; |
There was a problem hiding this comment.
What changed so we no longer need this? Sorry I don't have the context.
Yea, exactly. @chenba the original issue is here: #289 as Taddes said, reqwest with its Apparently sentry changed its default a long time ago, not that long after our original workaround, to reqwest w/ the pure rust |
3 participants
Description
(we were missing the "capture" feature)
and switch back to sentry's now longstanding default transport of reqwest+rustls, which avoids issues w/ our grpc client's included boringssl that occurred w/ reqwest+native-tls
Issue(s)
Closes STOR-493