Incorrect span count and matching span count in traces list when fetching latest traces

While fetching recent traces on traces list (link), it seems that few traces have incorrect span count and matching span count.

The SQL query logic that runs in the backend is logically sound and is confirmed if we can reverse the sort duration to ascending for the same call.

I think that this is because while fetching the latest traces we calculate over incomplete information i.e. on traces that are still being ingested.

We can try a solution of delaying the end timestamp by a minute or so.