Repository navigation
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 |
rmunn
added a commit
that referenced
this pull request
Nov 12, 2026
A never-synced project's entries count as edited in LF only if they carry a user reference (#362), because LfMerge clears those on every entry it writes. A LIFT import into LF leaves none either, so on an LF project's first Send/Receive -- as when one is migrated -- every imported entry was taken to be LfMerge's own and left out. The transfer back to Mongo then marked each of them deleted, since FieldWorks did not have it: 12,638 of a test project's 14,370 entries, and 47,827 entries across the projects due to be migrated. FieldWorks cannot hold a newer version of an entry it does not have, so in a never-synced project such an entry is now sent. Entries FieldWorks has are still left to FieldWorks, as #362 intended. The one case this changes besides migration is an entry LfMerge wrote on an initial clone and FLEx then deleted, before any sync was recorded: it now comes back instead of staying deleted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Nov 12, 2026
rmunn
added a commit
that referenced
this pull request
Nov 12, 2026
…orks (#365) * Send a never-synced project's missing entries only to an empty FieldWorks #361 made LfMerge send every entry a never-synced project's FieldWorks lacks, so that an LF project's first Send/Receive -- as when one is migrated -- would not lose the entries a LIFT import into LF left without user references. But it did that for every never-synced project, and the ones whose FieldWorks already has entries were cloned from it: the entries it lacks were since deleted in FLEx, or dropped when its repository was begun afresh. Their next sync would bring those entries back, undoing what #362 was for. Three never-synced projects on the live server are like that, with 664 such entries between them. So the missing entries are now sent only when FieldWorks had no entries at all before the conversion began, which is how a migration's new LexBox project starts. Every other never-synced project is back to how #362 left it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Log each never-synced entry taken to be deleted in FLEx In a never-synced project whose FieldWorks has entries, an LF entry with no user references that FieldWorks lacks is taken to have been deleted in FLEx since the initial clone, and the transfer back to Mongo marks it deleted. The data cannot check that: an entry imported into LF from LIFT after the clone looks just the same, and would be marked deleted too. That is deliberate, but it should not pass unnoticed. Each such entry is now logged by GUID and name as it is left out, so that one which turns out to be LF's own can be found and restored -- marking it deleted leaves it in Mongo. The comment there now says this is an assumption, and names the case it gets wrong. After a sync nothing is logged: an entry FieldWorks lacks then was certainly deleted in FLEx. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.