I have seen this issue described in a ticket from 2019 where it was seen as "not reproduceable".

The problem is that if a link to a subrepository in git is broken on any branch, the next build on all other branches (with correct links) will fail.

Workaround is restarting the build, which is really bad for continuous integration.

How to reproduce:

Create a main repository ("surface") and a sub repository ("sub").

Populate them and make "sub" a sub repository of "surface".

Create a multibranch pipeline job scanning "surface" for new branches.

Verify that the main branch of repo "surface" compiles (make it easy, all I did was having a Jenkins file with "echo hello" in it).

Now create a new branch of "surface" locally, with a new version of the "sub" repository.

Push you new branch only to "surface" (don't push "sub").

The multibranch pipeline will pick up the new branch and correctly fail it.

Check out the main branch of "surface" locally, and create a new commit on it. Keep the version of "sub" that is already available in the central repository. This is a valid combination of surface/sub on the git server and will compile correctly.

Push the main branch to the "surface" repository and the multibranch pipeline will start running the main branch. 

Notice that the build will fail. 

The error message (shortened):
ERROR: Error fetching remote repo 'origin'00:00:01.576 hudson.plugins.git.GitException: Failed to fetch from <server>

fatal: remote error: upload-pack: not our ref ...
fatal: git upload-pack: not our ref ...

What happens is that the fetch will look for the irrelevant subrepo refernce in the bad feature branch. (Typically this is on a feature branch.)

The build will fail, but if you restart the job the next build will be ok.

I hope this is enough to reproduce.