j1wonpark opened a new pull request, #4349: URL: https://github.com/apache/amoro/pull/4349
## Why are the changes needed? Fix #4348. Since #4116, `ProcessService` constructs `DefaultTableProcessStore` passing the *current* retry count into the constructor's `maxRetryTime` parameter. A new process therefore gets `maxRetryTime = 0` and becomes terminal on its first failure, every subsequent transition is rejected, and `retryNumber` never increases — while the retry branch in `executeOrTraceProcess` keeps evaluating `retryNumber < PROCESS_MAX_RETRY_NUMBER` as true and resubmits the process forever, with no backoff. ## Brief change log - Construct `DefaultTableProcessStore` with `PROCESS_MAX_RETRY_NUMBER` as `maxRetryTime`, in both the creation and the recovery path (restores the pre-#4116 semantics of #3924) - Only resubmit a failed process when its `RETRY_REQUESTED` transition is actually accepted, so a rejected transition can never loop - Add a regression test verifying a persistently failing process is retried exactly `PROCESS_MAX_RETRY_NUMBER` times and then dropped ## How was this patch tested? - [x] Add some test cases that check the changes thoroughly including negative and positive cases if possible `TestDefaultProcessService#testFailedProcessRetryIsBounded` reproduces the infinite loop before the fix (the process is never dropped and the wait times out) and passes after: the failing process is submitted `1 + PROCESS_MAX_RETRY_NUMBER` times in total and then untracked. Existing process service tests all pass. - [x] Run test locally before making a pull request ## Documentation - Does this pull request introduce a new feature? (no) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
