Exception Handling in SQS Listener

[rohit1636]

Hi Folks,

Is there any way to disable the AWS library specific exceptions being wrapped around our own custom exceptions. Because we have a use case to implement business logic based on the type of exceptions that are raised. We tried searching about it , but couldn't find any proper answer to disable it at library level.

And also is there any other way to achieve this ?

Any kind of help is appreciated. Thanks a lot in advance !

[tomazfernandes]

Hi @rohit1636, you mean AWS SDK exceptions? You'd need to check with them.

I'm not sure I understand what you're trying to accomplish - would you mind providing more details?

Thanks.

[gbataille]

Hi @tomazfernandes ,

It's been a while but I found this ticket and I think I have the same ask are @rohit1636 .

Basically I have @SqsListener setup to react to SQS messages.
When my processing throws an error, it appears in the logs wrapped in a few layers of SDK exceptions that are of little use to me (except maybe for the message ID but I'm ok to loose that)

07:58:46.927 ERROR 16206 [    messaging-2] tMessageProcessingPipelineSink traceId=68ccf11652a7600b6d0c2bd6a935a38a, spanId=6d0c2bd6a935a38a, userId=0000MESSAG1NG : Error processing message a197e40c-ebe4-466d-a7c1-7cf1c1821ce3.

java.util.concurrent.CompletionException: io.awspring.cloud.sqs.listener.AsyncAdapterBlockingExecutionFailedException: Error executing action in BlockingMessageListenerAdapter
	at java.base/java.util.concurrent.CompletableFuture.wrapInCompletionException(CompletableFuture.java:325)
        ...
Caused by: io.awspring.cloud.sqs.listener.AsyncAdapterBlockingExecutionFailedException: Error executing action in BlockingMessageListenerAdapter
	at io.awspring.cloud.sqs.listener.AsyncComponentAdapters$AbstractThreadingComponentAdapter.wrapWithBlockingException(AsyncComponentAdapters.java:178)
	...
Caused by: io.awspring.cloud.sqs.listener.ListenerExecutionFailedException: Listener failed to process messages a197e40c-ebe4-466d-a7c1-7cf1c1821ce3
        ...
Caused by: java.lang.RuntimeException: Exception thrown by me
	at tech.lightframe.shift.shared....

Those layers are preventing the identification and triage of the exception.
All the SqsListener exception look the same from the top and create the same kind of alert / ticket in our monitoring system.

My ask (and I guessing the ask of this ticket) is whether this could be removed. But looking at the code I doubt this is possible (in the current code base at least)

I'm wondering if using our own MessageListenerContainer would give us more control.

If you have some pointers, I would appreciate it.

Thanks

[rohit1636]

Hi @gbataille , I am sharing the workaround that we had done to find out the actual exception using the below piece of code. Hope it helps !

public static Exception findRootCause(Throwable throwable) {
		var cause = throwable.getCause();
		if (cause == null && throwable instanceof Exception exception) {
			return exception;
		}
		else if (cause == null) {
			return new Exception(throwable);
		}
		return findRootCause(cause);
	}

[gbataille]

Hi @gbataille , I am sharing the workaround that we had done to find out the actual exception using the below piece of code. Hope it helps !

public static Exception findRootCause(Throwable throwable) {
		var cause = throwable.getCause();
		if (cause == null && throwable instanceof Exception exception) {
			return exception;
		}
		else if (cause == null) {
			return new Exception(throwable);
		}
		return findRootCause(cause);
	}

yup. Thanks. I did something in that direction too, putting a filter before sending the stack trace to our monitoring tool. That's a bit unsatisfactory but it works!

[tomazfernandes]

Hey @gbataille and @rohit1636.

I think it makes sense not to log framework-specific exceptions if they don't add much value to the end user.

Errors are logged in AbstractMessageProcessingPipelineSink#logError, we could add logic there to remove known framework exceptions such as AsyncAdapterBlockingExecutionFailedException and ListenerExecutionFailedException from the Stacktrace / causes.

Given we're now working towards a major release, we could consider making that the default behavior.

Feel free to open an issue if that makes sense to you, and PRs are welcome!