[YevheniiKotyrlo]

Summary

When a delta build fails, getDelta puts back the change sets it took as a plain union with the changes that arrived during the build. A file that changed both before and during the failed build ends up in two sets:

• deleted, then recreated: in _addedFiles and _deletedFiles, so the next delta skips the file and the client keeps the old module;
• modified, then deleted: in _modifiedFiles and _deletedFiles, so the next delta traverses a deleted file.

The failing build is often the one the deletion started, an import that no longer resolves, so the window is that build's whole duration: 11.7 s where I hit it, an iPad loading from Metro on Windows.

The fix restores the taken sets and replays the later changes on top of them through the transitions _handleMultipleFileChanges uses, extracted as #markAdded, #markModified and #markDeleted.

(Added by @robhogan: Also cover the related case where a file is deleted and re-added during a successful build, so that we remember to treat it as modified for the next build)

Changelog: [Fix] Track files changed during a delta build correctly, so the next delta rebuilds a recreated file and skips a deleted one

Test plan

• Two DeltaCalculator-test.js cases, run for posix and win32 paths: a file deleted and recreated during a failed build is traversed by the next delta, and a file modified and deleted during one is not. All four fail on main and pass with the fix.
• yarn typecheck, typecheck-ts, lint, format-check, build, test-smoke and test-coverage (151 suites, 2760 passed, 26 skipped).
• On the iPad, deleting a directory the screen imports and recreating it while the failed build runs: on main the next update carried 7 modules and none of the 20 recreated ones, and the screen kept the old text; with the fix it carries all 20 and the screen updates.

[robhogan]

Thanks again!