I believe often this is a side-effect of having one upstream pipeline manually triggered (infrequently) which shares a material with another upstream pipeline which is auto-triggered on each commit - and sometimes due to use of inconsistent filters on triggers for the same material (allowlists or denylists for particular paths in the repo). It's difficult to comment on your specific case without some kind of
description of the topology of your pipelines and triggers but generally I find this
is due to pipeline design or material/repo structure challenges where people have relied on trigger filters in ways that "breaks" or prevents fan-in.
GoCD is basically saying "I tried to go back a long way (100 revisions by default) through the ancestor pipelines and couldn't find a successful build of the relevant ancestors which could be traced to matching/consistent material revisions so I gave up".
Assuming you do want fan-in semantics and revision matching across your server, you can increase the limit by setting the system property -Dresolve.fanin.max.backtrack.limit=200 (default=100) but I am not personally sure of the implications of that for performance, especially not in your specific case - and it may not get to the root cause of why in your pipeline/trigger design it is difficult for GoCD to resolve a common ancestor, so may not solve the real problem.
One way of debugging this is to identify the problematic shared material, and then view the Value Stream Map from the perspective of individual commits and see which downstream pipelines actually had builds triggered for that commit. The ones that didn't trigger might have filters, failures or manual approvals preventing the later fan-in.
-Chad