Skip to content

Fix swallow OptimisticLockingFailureException as GenericSpServerExcep…#3082

Closed
vasilchev wants to merge 1 commit into
eclipse-hawkbit:masterfrom
boschglobal:fix/retry_optimistic
Closed

Fix swallow OptimisticLockingFailureException as GenericSpServerExcep…#3082
vasilchev wants to merge 1 commit into
eclipse-hawkbit:masterfrom
boschglobal:fix/retry_optimistic

Conversation

@vasilchev
Copy link
Copy Markdown
Contributor

…tion that prevents @retryable(includes = ConcurrencyFailureException.class) to work as expected

Having entry 'OptimisticLockingFailureException' in 'MAPPED_EXCEPTION_ORDER' but not in 'EXCEPTION_MAPPING' (leftover) forces ExceptionMapper to map it to 'GenericSpServerException' which then breaks completely all the annotations for retry:
@Retryable(includes = ConcurrencyFailureException.class,

Removing it from 'MAPPED_EXCEPTION_ORDER' now just returns it as is -> 'ConcurrencyFailureException' that will be handled by the '@retryable' annotations.

…tion that prevents @retryable(includes = ConcurrencyFailureException.class) to work as expected

Signed-off-by: vasilchev <vasil.ilchev@bosch.com>
@vasilchev
Copy link
Copy Markdown
Contributor Author

Wrong assumption - @retryable is executed - it searches/compares the Exception with traversing=true (looping all exception causes as well, not a direct match).

Having this said, retry is there, just Exception after the retries is mapped to Generic, because of missing mapper.

If we completely remove the MAPPER, OptimisticLockException would be return to caller (could be REST) which is not a great design (at least custom exception should be returned). Better would be to actually introduce back a custom mapped exception for it

@vasilchev vasilchev closed this May 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant