-
Notifications
You must be signed in to change notification settings - Fork 34
(fix) O3-4985: End current queue entry when transitioning before checking for possible duplicates #85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(fix) O3-4985: End current queue entry when transitioning before checking for possible duplicates #85
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -13,6 +13,7 @@ | |
| import static org.junit.Assert.assertNull; | ||
|
|
||
| import java.util.Arrays; | ||
| import java.util.Date; | ||
| import java.util.List; | ||
|
|
||
| import org.junit.Before; | ||
|
|
@@ -47,26 +48,23 @@ public void setup() { | |
| INITIAL_DATASET_XML.forEach(this::executeDataSet); | ||
| } | ||
|
|
||
| @Test | ||
| @Test(expected = DuplicateQueueEntryException.class) | ||
| public void transitionQueueEntryShouldNotEndInitialIfNewIsDuplicate() { | ||
| QueueEntry queueEntry = queueEntryService.getQueueEntryById(3).get(); | ||
| QueueEntryTransition transition = new QueueEntryTransition(); | ||
| transition.setQueueEntryToTransition(queueEntry); | ||
| transition.setTransitionDate(queueEntry.getStartedAt()); | ||
| try { | ||
| queueEntryService.transitionQueueEntry(transition); | ||
| } | ||
| catch (DuplicateQueueEntryException ex) { | ||
| assertNull(queueEntryService.getQueueEntryById(3).get().getEndedAt()); | ||
| } | ||
| queueEntryService.transitionQueueEntry(transition); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This looks right to me (the pre-existing assertNull is not actually testing any aspect of transactionality, it is just testing whether that property was set before the exception occurred, so fine to remove that. |
||
| } | ||
|
|
||
| @Test | ||
| public void transitionQueueEntryShouldEndInitialIfNewIsNotDuplicate() { | ||
| QueueEntry queueEntry = queueEntryService.getQueueEntryById(1).get(); | ||
| QueueEntry queueEntry = queueEntryService.getQueueEntryById(2).get(); | ||
| assertNull(queueEntry.getEndedAt()); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is this change needed? How is this related to the PR?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The test was not valid. Queue entry 1 is initialized to have a non-null |
||
| QueueEntryTransition transition = new QueueEntryTransition(); | ||
| transition.setQueueEntryToTransition(queueEntry); | ||
| transition.setTransitionDate(queueEntry.getStartedAt()); | ||
| assertNotNull(queueEntryService.getQueueEntryById(1).get().getEndedAt()); | ||
| transition.setTransitionDate(new Date()); | ||
| queueEntryService.transitionQueueEntry(transition); | ||
| assertNotNull(queueEntryService.getQueueEntryById(2).get().getEndedAt()); | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have tests/can we confirm that throwing this exception causes the "saveQueueEntry" listed above to be rolled back (which I think was what this fix was trying to achieve).
I would assumed it would be if the method is transactionally, but would be good to verify (which there is likely already a test for, just wanted to confirm).
Alternatively, could the isDuplicate check be changed to be smart enough to ignore the queueEntryToStop when checking for duplicates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is pretty difficult to test any real transactional behavior in our context-sensitive unit testing framework @mogoodrich . I don't think we really do so anywhere, across all of OpenMRS, to be honest, except in very limited cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair... I guess, can we confirm manually at least that this works? Or just sanity check for me that's what is supposed to happen, correct? The PR wasn't showing enough to see whether there was a transactional annotation on the parent method (though I assume there was). It's just that if it doesn't work it defeats the whole purpose of the initial commit in the first place, if I'm understanding correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chibongho if you can manually test the webap and confirm that the original problem which was reported by @denniskigen is still fixed with these changes, i will approve this pull request. 😊
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Manually tested in RefApp version 3.6.0-SNAPSHOT with changes in PR:
Verified that: