Enrich transactions with Scope and Device context

[marandaneto]

We might need to decide field per field, what makes or not sense setting in the transaction (compared to SentryEvent), tags should be merged as tags are indexed and searchable.

Related issue #1163 (comment)

[marandaneto]

@bruno-garcia @maciejwalkowiak @Tyrrrz @brustolin we need to discuss here which fields make sense to be part of a transaction or not.

[brustolin]

Well, now that the return of startTransaction is a span, this is kind decided, because the user has no access to transaction fields to changed it. But, I agree with Bruno that the Sentry Protocol UI should have all information about the app project. So, when transmitting the transaction, the easier solution is to create an Event that already capture project information and populate with the transaction missing information.

[marandaneto]

@brustolin not really, this is more about all the data that the SDK sets automatically eg device context, scope's data, etc, so technically this is still not decided, I'd say that the best solution is, we want transactions to be as rich as an event, but we also want transactions to be cheap, so we don't want all the information (eg calculating app's device storage, available memory, etc) would be affecting device's memory footprint and the performance of the App/SDK itself quite a lot.

[bruno-garcia]

SDKs that have a Transaction be literally a SentryEvent with type=transaction they get all contexts that comes up on an event. The positive part of it is that the transaction is rich in context, but the drawback is that some of these values can be expensive to retrieve and the general payload can get rather large. What data we get from Spring vs Android will also vary since on a server there could be hundreds of transactions per second, and on mobile maybe only 1 or 2 but the device can be offline, low on storage, on 2g so connected but slow. So we need to account for those differences and add focus on the most relevant context data first. We can also add more data as we go along, but pulling data out is more of a breaking change.

Particularly on Android we have some lookups that aren't very cheap when we capture an event. We could make update these values in the background and have transactions include them while partially outdate (a few seconds) like storage for example? Or do we include it anyway? Or is it better to not include storage at all? That's what needs discussion mostly.

[marandaneto]

yep, these are the trade-offs, and we have to talk about them.

[marandaneto]

if we'd like to breakdown the pXX per OS version, App version or Device (eg family), we'd need to enrich our transactions with these device's context.

[Tyrrrz]

Currently, in .NET we copy everything from the scope to the transaction.
That only includes values that the user has set explicitly though.

[marandaneto]

#1430