Maximum Backtracking limit reached error

31 views
Skip to first unread message

Pedro Carriço

unread,
Mar 1, 2023, 11:11:27 AM3/1/23
to go-cd
Hi,

Recently I've been having the following error:

"Error while scheduling pipeline: smoke-tests- Feb, 2023 at 12:14:00 Local Time
Maximum Backtracking limit reached while trying to resolve revisions for material DependencyMaterialConfig{pipelineName='app-staging', stageName='deploy'}"

I can't find anything recent regarding that error or how to fix it, this just started happening and seems to go away if I trigger the pipeline manually or if another commit triggers the upstream pipeline. That specific pipeline is also in the middle of a fan-in pipeline.

How am I able to fix this error or debug what's happening?

Thanks





Chad Wilson

unread,
Mar 2, 2023, 4:23:30 AM3/2/23
to go...@googlegroups.com
You might want to have a read of https://github.com/gocd/gocd/issues/1583

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

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/dc19ee7b-f937-42a7-8505-71990f588f60n%40googlegroups.com.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages