tracing: client options and Hub/Scope API#288
Conversation
4b93609 to
1e1de33
Compare
| /// Sets the transaction name. | ||
| pub fn set_transaction_name(&mut self, name: Option<&str>) { | ||
| self.transaction = name.map(|txn| Arc::new(txn.to_string())); | ||
| // TODO: Update transaction name (not feasible with Arc<Transaction<'static>>) |
There was a problem hiding this comment.
Or we would have to wrap it in a rwlock maybe?
|
Apologies for the staleness, I've been busy contributing to other projects but will get back to this ASAP |
8f79569 to
b65fda3
Compare
cbb5bdb to
fe33223
Compare
fe33223 to
fa52520
Compare
fa52520 to
136bcc3
Compare
|
Hello. |
|
Has there been any progress on this? I would find this rather useful in my projects :) |
|
I can see there is some interest in this, but I'm choosing to close it. The current SDK architecture for tracing is heavily dependent on OOP concepts, and IMO the SDK Guidelines for Tracing will need a lot of clarifying for them to apply to a wider set of languages. The current implementations are in Python and JavaScript, which allow for a lot of liberties that Rust simply cannot take. There's also a lot of backward-compatibility legacy code in them which makes it even harder to understand what's going on. Of course, actual Sentry developers may have more insight in implementing the required architecture changes, but I feel like I'm constantly fighting the language to get any results. Hopefully some of the code here will become useful down the line to another contributor or to the Sentry team. |
|
Oh, alright, that's understandable. |
Hi again! I'm opening this PR to further the discussion on integrating tracing/APM here. I'd like to scope this PR to implement the basics of the tracing API. This includes
traces_sample_rateandtraces_samplerScope:set_spanandget_transaction(WIP)trace_headers,start_transactionstart_transactionFor now I'd appreciate a review on how I implemented the new functions in
Scope. I'm still unsure of how theSpan <-> Transactionrelation will be implemented, so I assumedSpan.transactionwould beArc<Transaction<'static>>. However, that makes the transaction immutable and thus breaks this guideline:Alternatively, the transaction could be owned by the Scope instead of propagating references in individual Spans. Not sure if that's preferred.
Also if there's another preferred medium for chatting about design stuff like this let me know ^.^