VMR codeflow check reports incorrect dependency flow issue

[mmitche]

Pull request

dotnet/dotnet#1763

Type of problem

Unexpected behavior in the PR (e.g. conflicts, EOLs, mangled files, ..)

Description of the issue

dotnet/dotnet#1763 (comment)

[premun]

Is it possible we're storing the "latest applied build" into Redis even when we fail to flow the changes because of a conflict? And then the contents of the files obviously does not match the versions and SHAs from that build?

[premun]

I suspect something like this could be happening:

• We have an open PR
• A new build happens and we try to add it in the PR
• There is a conflict so we fail to flow the code and we put up a comment "can't flow because of a conflict"
• Yet we store in Redis that the build got applied
• The check now fails because it expects different SHA

[premun]

It seems like something else was happening (here dotnet/dotnet#1887):

• A PR opened correctly
• A new build flowed into the PR correctly
• A third build 280001 triggered the subscription, it started flowing into the PR and the following happened:
  • Logs don't report any problem and look like changes were processed fine
  • The PR received a single commit - a merge of the target branch into the PR branch
  • The PR didn't receive any new file updates (though there were some since the previous build)
  • Nor the source-manifest got updated
  • The PR description DID get updated to match the new build

So it seems like the service thought the new build was applied but these changes were not committed (?) so the files lagged behind. Interestingly enough, the branch merge happened, which happens after we update the files. So it just seems like maybe we staged file updates but those didn't get committed or something and silently we continued to the later stage of merging the target branch.

[dkurepa]

We made a lot of changes to Maestro recently, and we think that one of these fixed the issue. We haven't seen this issue happen in some time, so we're closing the issue, and will re open it if something happens again

[dkurepa]

Something like this happened today:

• An existing FF runtime PR got updated with a new commit, but it looks like the Maestro cache didn't get updated with inforamtion about the new build, causing the verification to fail

dotnet/dotnet#2908