Fix incorrect handling of fresh clone - #362
Merged
Merged
Conversation
If a project's Mercurial repo has been deleted from webwork and LfMerge clones a fresh copy of the LexBox repo, the fresh copy may be at a different Mercurial revision than the one that LfMerge last synced from. If that happens, then our modifiedDate handling, which only checks if the FLEx modified date is *different* from the Mongo copy, can incorrectly flag a copy modified in FLEx as having been modified in LF, and therefore overwrite FLEx's *newer* data with LF's *older* data. This has already happened to one project, and I had to roll back the Mercurial revision that LfMerge made, because it had replaced several hundred FLEx entries (modified in 2026) with stale LF entries last modified in 2024. The code in this commit was created by Claude Opus 5.5 after examining the state of that particular project; I (Robin Munn) will be making a few changes in later commits, mostly to reduce the verbosity of the comments that Claude always includes. But the logic is correct, and should prevent this problem from happening again.
Tests now depend on LastSyncedDate being correct, since the Mongo->LCM logic relies on it now in order to detect cases where FW work went on while LF didn't know about it. So the test double needs to refresh its LastSyncedDate value the same way that the real object does, in order for the unit tests to be correctly simulating the real thing.
rmunn
force-pushed
the
bug/fix-incorrect-fresh-clone-handling
branch
from
October 1, 2026 06:21
220792e to
4f382fd
Compare
Collaborator
Author
|
Tests are confirming it works as expected. On a small test project, the LfMerge version currently in production would have replaced 77 FLEx entries that were newer than LF with the LF entries that had not actually been modified, but running an LfMerge built from this branch instead logged a message saying "77 entries in FLEx are newer than LF" and correctly replaced LF's older data with FLEx's newer data. I'll try a couple more, but this LGTM. @hahn-kev gave a verbal thumbs-up, so I will probably merge this bugfix into |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If a project's Mercurial repo has been deleted from webwork and LfMerge clones a fresh copy of the LexBox repo, the fresh copy may be at a different Mercurial revision than the one that LfMerge last synced from. If that happens, then our modifiedDate handling, which only checks if the FLEx modified date is different from the Mongo copy, can incorrectly flag a copy modified in FLEx as having been modified in LF, and therefore overwrite FLEx's newer data with LF's older data.
This has already happened to one project, and I had to roll back the Mercurial revision that LfMerge made, because it had replaced several hundred FLEx entries (modified in 2026) with stale LF entries last modified in 2024.
The code in this PR was created by Claude Opus 5.5 after examining the state of that particular project; I will be making a few changes in later commits, mostly to reduce the verbosity of the comments that Claude always includes. But the logic is correct, and should prevent this problem from happening again.