[UI] Race condition when clicking on a large track immediately before performing area selection

[cphlipot1]

It seems like on recent versions of the UI there is an issue where it takes the UI a long time to respond after clicking on a counter track with a large number of values. If the user performs an area selection after clicking the area selection will complete first, and then later the output will get overridden later with the single value selection.

Based on the symptoms like looks like a possible race condition that is being triggered by a recent regression is single counter value selection latency.

This issue seems to impact any trace that has a large counter track, but all of the simplest reproducers for this issues will require https://android-review.googlesource.com/c/platform/external/perfetto/+/3441062 in order not to crash

How to reproduce

1. apply https://android-review.googlesource.com/c/platform/external/perfetto/+/3441062 locally
2. build the UI from source and run the ui devserver
3. open large_power_rail_trace.pftrace.gz in the UI
4. expand the power rail tracks.
5. click on one of the tracks, and then immediately perform an area selection on that track.
6. Observe that when the UI finally responds a single counter value is selected instead of the area which was expected.

Note: it may not be obvious in the video, but i do left click (press & release) on the 2nd power rail track before i perform the area selection at about 1/2 second into the video

Screen.Recording.2025-01-07.at.4.06.10.PM.mov

[LalitMaganti]

I've asked @stevegolton to look at this. It may take us a bit of time to fix this though: we are in the process of overhauling how aggregation/search work.

[cphlipot1]

Also just wanted to note this seems to impact stable, canary, and autopush for traces that are not impacted by #980

I don't I was very clear on that in the original issue description.

I've asked @stevegolton to look at this.

Thanks!

[cphlipot1]

While the race condition would still be present, it looks like it could be significantly mitigated by optimizing the queries.

I put up https://android-review.googlesource.com/c/platform/external/perfetto/+/3439249 which should make the queries involved here run about 1 order of magnitude faster with the trace attached to this bug.

This does not make the race condition go away, but it makes it more likely for the first query to finish before the user can make a second click, and i think perf improvements here are worthwhile for UX regardless as single counter value selection would take ~10 sec on the attached trace without this CL.

[stevegolton]

The race should be fixed by https://android-review.googlesource.com/c/platform/external/perfetto/+/3444861