For many years now, perf datum were associated to a single job; that job is directly associated to a single push (from mozilla-central), which in turn is associated to a single push timestamp (the actual time when the push was made). Which is a normal assumption.
For our new use case in particular, each new perf datum is still associated to a single job, but these jobs are not necessarily directly associated to a single push (from mozilla-central), rather to multiple pushes from fenix repo. Fenix pushes which in turn are associated to distinct push timestamps.
I looked a bit into the pipeline code (residing in perf.py).
This piece of datum ingestion code is currently shadowing the ingestion of new data points pertaining to the same mozilla-central push.
Not entirely sure about this, but it's possible we can fix this shadowing issue by tweaking this datum ingestion line.
Instead of simply fetching & updating perf data based on its job's push's push_timestamp, we can consider to fetch & update it based on its specific fenix push's push_timestamp. If there is one; if there isn't (the old default behavior), we simply fallback to the old fetching & updating algorithm.
Basically, we would simply need to extend the fetch & update ability we currently have for our perf data.
From my experience, this seems the way to do it. Still, I'm not 100% sure about this & we could uncover some unexpected problems along the way (requiring either refactors or a different approach).
Going with the preliminary solution I proposed, the code changes aren't big. The gist of the fix would be to provide proper test coverage & QA on the staging environments before we release a change like this to production. I stress this out because the ingestion pipeline is the most important & yet intricate part of Perfherder/Treeherder.