For the mobile starfish app start module we want to allow users to be able to filter their spans by warm/cold start. We've decided to propagate a start type property in span data to facilitate this filter.
I propose adding a key called app_start_type to the span data field (docs on the data field) which can either have a value of cold or warm.
### Tasks
- [ ] Android: Tag all spans with `app_start_type`
- [ ] iOS: Tag all spans with `app_start_type`
- [ ] React Native: Tag all spans with `app_start_type`
- [ ] Flutter: Tag all spans with `app_start_type`
- [ ] https://github.com/getsentry/relay/pull/3027
The linked Relay PR will start filling in app_start_type by checking the measurements on a transaction to see if there is app_start_warm or app_start_cold timing. If the value is provided in the data field, then that will take precedence. This is so we can take advantage of the filtering before waiting for new SDK adoption, but will support extraction when moving towards span streaming.
It was suggested to use app context but it seems like Android may be missing the start type for certain transactions, e.g. see here. This seems like the most consistent method across Android and iOS at the moment.
For the mobile starfish app start module we want to allow users to be able to filter their spans by warm/cold start. We've decided to propagate a start type property in span data to facilitate this filter.
I propose adding a key called
app_start_type
to the span data field (docs on the data field) which can either have a value ofcold
orwarm
.The linked Relay PR will start filling in
app_start_type
by checking themeasurements
on a transaction to see if there isapp_start_warm
orapp_start_cold
timing. If the value is provided in the data field, then that will take precedence. This is so we can take advantage of the filtering before waiting for new SDK adoption, but will support extraction when moving towards span streaming.It was suggested to use app context but it seems like Android may be missing the start type for certain transactions, e.g. see here. This seems like the most consistent method across Android and iOS at the moment.