Refactor deletion of dangling labels #1606
Merged
Conversation
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
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1606 +/- ##
=======================================
Coverage 94.77% 94.78%
=======================================
Files 130 130
Lines 3330 3334 +4
=======================================
+ Hits 3156 3160 +4
Misses 174 174 ☔ View full report in Codecov by Sentry. |
Mathis-Z
approved these changes
Aug 26, 2024
I knew you would point that out. It is not used, that's right. I found it helpful to have while debugging, since it replaced the magic object ID with the actual label name when printing. If you like, I can add a simple test for that. |
|
The test is a bit silly 😉 but at least Codecov is happy now 👍 |
MrSerth
added a commit
that referenced
this pull request
Sep 11, 2024
We recently discovered an edge case where a moved file was not updated correctly. At first, it got removed and recreated, and later on only removed. While these changes look pretty difficult, they are the best and only working approach I could find to fix the problem ;). For now, I'd suggest to go with this solution. See #1606 for more details.
kkoehn
pushed a commit
that referenced
this pull request
Sep 16, 2024
We recently discovered an edge case where a moved file was not updated correctly. At first, it got removed and recreated, and later on only removed. While these changes look pretty difficult, they are the best and only working approach I could find to fix the problem ;). For now, I'd suggest to go with this solution. See #1606 for more details.
kkoehn
pushed a commit
that referenced
this pull request
Sep 17, 2024
We recently discovered an edge case where a moved file was not updated correctly. At first, it got removed and recreated, and later on only removed. While these changes look pretty difficult, they are the best and only working approach I could find to fix the problem ;). For now, I'd suggest to go with this solution. See #1606 for more details.
The previous mechanism required newly-assigned TaskLabels to be saved before aiming to destroy dangling labels. However, there is one edge-case previously used in the tests which caused erroneous behavior: Imagine, there is a dangling label (with no matching TaskLabel). Then, a task is assigned that dangling label through the `label_names=` mechanism. This will cause the `Label.find_or_initialize_by(name:)` method to return the dangling label and assign that to the task. However, when this assignment is not saved it (and no `TaskLabel` record is created), the following call to destroy dangling labels also removed the one just assigned to a task. This caused errors in tests, when switching from `labels` to `label_names` in the TaskController specs to remove the use of unpermitted parameters and transactional fixtures. The new mechanism will still remove dangling labels, but only those associated with a TaskLabel just removed. Through the transactional setting of destroy hooks, this still ensures there aren't any leftovers.
Since a label is considered "unique" based on its name, overwriting `to_s` makes sense to aid debugging.
Dome-GER
approved these changes
Oct 15, 2024
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.
The previous mechanism required newly-assigned TaskLabels to be saved before aiming to destroy dangling labels. However, there is one edge-case previously used in the tests which caused erroneous behavior:
Imagine, there is a dangling label (with no matching TaskLabel). Then, a task is assigned that dangling label through the
label_names=mechanism. This will cause theLabel.find_or_initialize_by(name:)method to return the dangling label and assign that to the task. However, when this assignment is not saved it (and noTaskLabelrecord is created), the following call to destroy dangling labels also removed the one just assigned to a task.This caused errors in tests, when switching from
labelstolabel_namesin the TaskController specs to remove the use of unpermitted parameters and transactional fixtures.The new mechanism will still remove dangling labels, but only those associated with a TaskLabel just removed. Through the transactional setting of destroy hooks, this still ensures there aren't any leftovers.