Set rollout error state for failed creation, starting or deletion process #1359
Conversation
…reating or deleting a rollout.
|
Can one of the admins verify this patch? |
...repository-jpa/src/main/java/org/eclipse/hawkbit/repository/jpa/AbstractRolloutExecutor.java
Outdated
Show resolved
Hide resolved
| final Iterable<JpaAction> iterable = scheduledActions::iterator; | ||
| final List<Long> actionIds = StreamSupport.stream(iterable.spliterator(), false).map(Action::getId) | ||
| .collect(Collectors.toList()); | ||
| actionRepository.deleteByIdIn(actionIds); |
There was a problem hiding this comment.
please consider splitting action ids in the batches of 999(max entries in IN statement), because the TRANSACTION_ACTIONS is 5000
| rollout.setRetryCount(retryCount); | ||
| rolloutRepository.save(rollout); | ||
|
|
||
| if (retryCount >= maxRetries) { |
There was a problem hiding this comment.
consider moving the check up, so that we don't increase the retry count and don't perform the execution of rollout handling if the retry count is exceeded (potentially check the status of a rollout, if it is in Error_* do nothing)
|
@herdt-michael, |
Hi @avgustinmm , please excuse the late reply. In cases where an exception has occurred during the handling of a rollout creation, with the next scheduler run the same rollout is processed again. The issue arises because the old scheduler run was not fully completed and ended up in an unexpected state. In some cases, this resulted in a mismatch between the target count and the targets actually included. With an error handling concept, for example, the creation of a rollout should be stopped with an error state rather than "forcing" trying to create a possibly corrupt rollout. |
|
|
Not required anymore. |
Set rollout into error state in case of too many tries of starting, creating or deleting a rollout.