fix(route_manager history): move history update to after model save#160
Merged
crankynetman merged 1 commit intomainfrom Jul 7, 2025
Merged
fix(route_manager history): move history update to after model save#160crankynetman merged 1 commit intomainfrom
crankynetman merged 1 commit intomainfrom
Conversation
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 1655065 |
samoehlert
approved these changes
Jul 7, 2025
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.
We need to actually update the Entry change reason after we save the Entry model which then creates a history model for that change. Before, we were doing it in the serializer before the model is saved, which means that the query to the DB that looks for the appropriate historical_entry instance doesn't find anything because it's looking for the historical entry that hasn't been saved yet.
This is related to #138 and actually, I think, would have fixed it, but we came at it from a different (and frankly, I guess, wrong) angle. Because update_change_reason only edits a historical entry, not create a new one, but I was originally assuming that this function call was what created the historical entry in the first place. In #138 we "fixed" this issue by making sure that the database migrations went and edited all the history to have the default value which then means we technically were editing the comment for the wrong history entry.