"Squashing failed: Squash the commits locally, resolve any conflicts, then push the branch" occurs frequently and is extremely time consuming when combined with a merge train workflow

Summary

When using a merge train heavy workflow, where 15-20 minutes are spent for each merge train, final squash failures are extremely costly and difficult to predict or avoid.

The "squash-and-merge" strategy appears to effectively replace the source branch with a single version commit immediately before merging. This erases the history of the branch, including any merge bases created between when the original source branch was created and when "squash-and-merge" occurs thereby significantly decreasing the likelihood that the 3-way merge algorithm can perform the merge without a conflict. The strategy does not appear to be tested before running the merge train pipeline which often results in an extensive pipeline run which succeeds but ultimately causes merge train restart when squash-and-merge fails. When this occurs, the message Squashing failed: Squash the commits locally, resolve any conflicts, then push the branch is appended to the MR.

There do not currently appear to be any solutions other than "don't use squash-and-merge with merge trains" or "have all devs locally squash and force push".

Steps to reproduce

Create a new repo with one feature branch. Make changes that will cause a conflict if and only if the MR is squashed-and-merged. Start a merge train.

What is the current bug behavior?

Squash-and-merge causes merge failure after merge train pipeline succeeds.

What is the expected correct behavior?

Squash-and-merge should fail before merge train pipeline starts.

Results of GitLab environment info

SaaS Premium

Possible fixes

Don't use heavy merge train pipelines or don't use squash-and-merge.