Support transaction finishing automatically with 'idle timeout'

[SeanFeldman]

Fixes #1074

Add support to specify transaction idle timeout to finish an idling transaction.

• Add SentryOptions documentation under common options
• Raise an issue to internalize public TransactionTracer constructors for testing in milestone for v4 --> Internalize TransactionTracer constructors used for testing #2481

[jamescrosswell]

This could be achieved by extending TransactionTracer with an optional parameter for the timeout.

I imagine SDK users would want to do this by passing in a timeout via one of the Hub.StartTransaction extensions.

We probably need those additional extension methods before this functionality would be usable then right?

@SeanFeldman maybe worth showing how this would work in one of the sample projects, as a bit of a smoke test to make sure this is all wired up?

[SeanFeldman]

I imagine SDK users would want to do this by passing in a timeout via one of the Hub.StartTransaction extensions.

We probably need those additional extension methods before this functionality would be usable then right?

I don't know if it should be just an option or also an explicit option via extensions. For example, Java has it on SentryOptions

@bruno-garcia or @bitsandfoxes, do you have some context to share? Thank you.

[SeanFeldman]

We probably need those additional extension methods before this functionality would be usable then right?

@jamescrosswell, yep. That will be the last step once I know everything that's needed is in place.

[bitsandfoxes]

I imagine SDK users would want to do this by passing in a timeout via one of the Hub.StartTransaction extensions.
We probably need those additional extension methods before this functionality would be usable then right?

I don't know if it should be just an option or also an explicit option via extensions. For example, Java has it on SentryOptions

@bruno-garcia or @bitsandfoxes, do you have some context to share? Thank you.

I'm fine with having it as an explicit option. Maybe I'm missing something but what would be the benefit of putting it on the extension?

[SeanFeldman]

We probably need those additional extension methods before this functionality would be usable then right?

@jamescrosswell, yep. That will be the last step once I know everything that's needed is in place.

I believe these calls from a sample are import from the get go. Looking at what the API call will look like helps us go the right direction

I'm fine with having it as an explicit option. Maybe I'm missing something but what would be the benefit of putting it on the extension?

We have this as a default value in the options. Users shouldn't have to be concerned with that for the most part (and in fact, that's mainly used by us, on our auto instrumentation for UI frameworks). It's cheap to add overloads later but unless we're confident folks will need them to solve real use cases, default to leaving them out (API design 101: when in doubt leave them out)

@bruno-garcia, to confirm, you're saying we shouldn't add an extension method and stick to the initial SentryOption until the need emerges in something else. Is that accurate?

[bruno-garcia]

I'll be honest, I'm concerned this is opened for 3 weeks and is still in draft. But I haven't really looked at it since my first round of comments. @bitsandfoxes what are the next steps here?

[bitsandfoxes]

This looks good to me!

[jamescrosswell]

Looks good to me!

[bitsandfoxes]

🚀

Fixed now