-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[RHPAM-4872] Fix RepeatMode=FIXED when deleted records > RecordsPerTransaction #2374
Conversation
Quality Gate passedKudos, no new issues were introduced! 0 New issues |
jenkins do fdb |
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.
Looks good to me, good work @martinweiler
Just a minor comment related to the test timeout in case the test execution is close to 10 seconds, it could be greater.
// time difference between first and last should be around 10 seconds, even if the original command got split into two executions due to RecordsPerTransaction | ||
long diff = lastExecution - firstExecution; | ||
assertTrue(diff < 11000); |
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.
Test timeout is set to 10 seconds, so probably it could be greater in case to let this comparison as it is.
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.
@gmunozfe Thanks for the input. However, the test is not waiting for the NextRun=10s to actually getting executed, test execution should be done in ~4s. The reason I chose 10s for the NextRun parameter is to make the assert clearer.
Failed tests not related to changes:
|
@mareknovotny this is ready to merge |
This is following up on the work from #2292
The problem with job rescheduling still occurs when 'pagination' exists (There are more records to delete than the 'recordsPerTransaction' parameter). When this happens, in each page it ends up moving the date and time of next execution by not taking into account the date of the first page of the current cycle but using the current one.
This PR addresses the issue by storing the execution time of the original LogCleanupCommand.