It would be valuable if errors had a reference to the transaction that was active when the error occurred.
I suggest that we simply add an optional transactionId to the list of error properties in the intake API. In the Elasticsearch model I imagine this should be stored as transaction.id.
If possible it would be nice to get this out in the data model before 6.2. We can always improve the usage of this in the UI later, but having it in the model before 6.2 would be beneficial.
Crazy bonus idea: This might even allow us to remove duplicate information from errors that are already stored on the transaction. But that would potentially have serious downsides once we introduce sampling, as the active transaction might not have been sampled.
cc @elastic/apm
It would be valuable if errors had a reference to the transaction that was active when the error occurred.
I suggest that we simply add an optional
transactionIdto the list of error properties in the intake API. In the Elasticsearch model I imagine this should be stored astransaction.id.If possible it would be nice to get this out in the data model before 6.2. We can always improve the usage of this in the UI later, but having it in the model before 6.2 would be beneficial.
Crazy bonus idea: This might even allow us to remove duplicate information from errors that are already stored on the transaction. But that would potentially have serious downsides once we introduce sampling, as the active transaction might not have been sampled.
cc @elastic/apm