fix: message arrival ordering and values accumulation #120
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR consist of 3 bugs that was missed to address from the previous release. This PR should conclude all the missed issues (fixes are separated in different commit for easier review).
This was one of the main issue when I was proposing tools: make combine logic align with FIT Activity CLI #114 (other than the maintaining two separate code issue). It is to preserve the original messages arrival order when we decoding then encoding the FIT again.
Previously, all the messages that have no timestamp will be placed at the beginning, this was obviously an issue as some of them may need to be retrieved by arrival order. When I think about it again, actually we can track the messages ordering by injecting the previous timestamp into the message that has no timestamp field, then we can sort it again by the timestamp, now we get the ordering as close as the original order, even though it's not exactly the same, at least they done not overlap 👍 . The additional timestamp then is being removed before encoding.
In record messages, there are two fields that need to be accumulated when combine, first is distance, we have done it but it turns out still not correct, the other that we missed to accumulate is accumulated_power.
Distance incorrectness: previously, we only accumulate the combined session's record which have the same sport and only append as it is when sport is not the same (distance start at zero), when I take a look at this triathlon activity file which consist of swimming, cycling and running. every sport start from previous distance so if swimming end in 4km, cycling distance start at 4km, and so on. In previous logic, each sport session start at zero distance which is not correct. This has been resolve now.
Accumulated power: accumulation logic for this value is the same as distance, and it's have been implemented.
Fix minor UI: Sport Name was missing from Lap section.