When rebasing and submitting to github, workflows are run for the wrong paths

[alex-statsig]

trafficstars

This may be more of a github issue, but posting here to start since its specific to Sapling afaict.

Context

Github Actions let you run tests on PRs based on changed file paths. For example, our monorepo project has folders "folder_a/**" and "folder_b/**", which each have their own suite of tests. To accomplish this, we use github action path filtering to only run the workflow if its relevant to files in the PR:

  pull_request:
    branches: [main, releases/*]
    paths:
      - folder_a/**

Normally this means that every time I submit a new commit to the PR, the files related to my net changes (against the main branch) have their tests run. Ex. if I create a PR touching "folder_a", "folder_a" tests run. If I then add a commit touching "folder_b", then both "folder_a" and "folder_b" have their tests run. Finally if I remove the changes to "folder_a", only "folder_b" tests will run.

Issue

After rebasing a PR using sapling and resubmitting it, tests seem to run for the incorrect files. In a PR that only touches "folder_a", sometimes both "folder_a" and "folder_b" run. I've even seen only "folder_b" run once. I'm guessing this has something to do with the force pushing, and perhaps some back-to-back changes applied to the PR causing a race condition.

To resolve the issue, I can add a random change to any file (in folder_a or folder_b), resubmit the PR, then remove the change and resubmit again. The net commit on the PR is identical, but this seemingly forces it to correctly detect the files.

This has been happening to us for a while but we hadn't realize the cause until recently.

Unfortunately there aren't great logs to indicate exactly which files/commits triggered the workflow. I could try adding some logging via other actions to understand what may be happening. I'm happy to help debug this, but wanted to first see if anyone here had immediate ideas of the cause.

[alex-statsig]

I've filed a ticket with Github about this, but would it be possible to change anything on the Sapling side to prevent the double-synchornization? It seems the PR is first force-updated in such a way that the PR appears to modify tons of files, then the PR's base is updated afterwards which fixes the diff. This still causes actions to run for paths not actually modified. (I would expect github to then cancel those preventing them from actually incurring any cost, but it seems there is an issue atm where it doesnt)