The original PR #6651 ended up keeping the timestamp (+ cpuid) whose value is beyond the trim-after threshold, as it logically makes sense to have that endpoint's timestamp. However, when that's across a blocking syscall, it canbe far into the future and result in large time gaps in the trimmed trace. Instead, we throw out the timestamp, as the PR #6551 did in its first form. (Other options such as editing the timestamp seem worse.)
The original PR #6651 ended up keeping the timestamp (+ cpuid) whose value is beyond the trim-after threshold, as it logically makes sense to have that endpoint's timestamp. However, when that's across a blocking syscall, it canbe far into the future and result in large time gaps in the trimmed trace. Instead, we throw out the timestamp, as the PR #6551 did in its first form. (Other options such as editing the timestamp seem worse.)
Adjusts the unit test that tests this.
Issue: #6648