Unpredictable obsolete http blocking in Maven 3.8.1 on Github Actions

Github recently updated the default Ubuntu image used in Workflows to use Maven 3.8.1. In this version of Maven, access to repositories using http, rather than https, are blocked by default. I've updated the configuration in our settings.xml to unblock access to our self-hosted repository, and this has allowed builds to continue.

      - name: Setup Repo credentials
        # maven-settings-action v2.4.0
        uses: s4u/maven-settings-action@e967605742bd38de606cf6edb7c89349ce917c6a
        with:
          servers: |
            [{
                "id": "repo.releases.mirror",
                "username": "${{ secrets.REPO_USERNAME }}",
                "password": "${{ secrets.REPO_PASSWORD }}"
            }]
          mirrors: |
            [{
                "id": "repo.releases.mirror",
                "name": "repo.releases",
                "mirrorOf": "repo.releases",
                "url": "http://our-repo-url",
                "blocked": false
            }]

However, some branches have been failing during the deploy goal.

Error:  Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) on project hats:
ArtifactDeployerException: Failed to retrieve remote metadata com.groupid:artifactid:version/maven-metadata.xml:
Could not transfer metadata com.groupid:artifactid:version/maven-metadata.xml from/to repo.snapshots (http://our-repo-url/):
authentication failed for http://our-repo-url/com/groupid/artifactd/version/maven-metadata.xml, status: 401 Unauthorized -> [Help 1]

These branches have no issue downloading dependencies from our repository using the unblocked http URL. But when they get to the deploy step, and try to download the maven-metadata.xml from the same internal repository, it fails with a 401 Unauthorized. Some branches don’t exhibit this behavior at all. If we recreate the branches that do have the issue, with the exact same commits, they build fine. But then when we merge in changes from the main branch they start failing with the above issue again.

I suspect the issue is possibly in Github Actions itself, perhaps in a caching layer. But So far I haven't been able to reliably recreate the issue on demand. Some branches simply start failing because of this, and once that's happened we've been unable to get that branch to successfully deploy.

Does anyone have any idea what is going on here?