Configurable AbortController

[DimTheo]

Background

Currently the abort option used in consumer.stop() aborts all requests. Making it configurable to only abort the selected commands (like ReceiveMessageCommand) would allow to configure the consumer so that during graceful shutdown our code can abort ReceiveMessageCommand requests only, thus stopping receiving new messages while in the same time all currently processed queue messages can trigger the rest of the commands as normal.

If passing the commands in the stop method is not achievable, the commands could be passed during the initialization of the consumer.

Objectives

1. This feature would address some issues that may raise while using consumer.stop({ abort: true }). stop without the abort flag doesn't abort any ongoing ReceiveMessageCommand requests, while using the abort: true flag is error-prone for messages currently being processed.
2. Passing a selection of command to be aborted either in stop method or initialization of consumer allows for fine-tuning.

[nicholasgriffintn]

Hey, thanks for the feature suggestion.

Honestly, that sounds a little complex though and I'm not really sure if we have any use cases for our apps so not sure if it's something we could immediately prioritise, it's certainly one that we could think about or look at a PR for though.

[jpike88]

I have run into this problem as well... abort: true will cause a request to recieve a message to be aborted... that's not an error that need to be reported. I think at least extending documentation to include advice on what to do if abort: true is called.

The only reason I want to use abort: true is that I want my queue to cut off processing new messages at the exact time I want. If this is not a recommended use case it would be ideal to suggest that too.

While hiding errors isn't a good design call, your expertise and how you wrapped the SQS library would be good to include in handling the above case

value.consumer.on('error', (err) => {
		if (err.message?.includes('Request aborted')) {
			// ignore, consumer was stopped on purpose, aborting the call
		} else {
			core.reportError(err);
		}
	});

[nicholasgriffintn]

Hey, sorry for the delayed reply, my notifications are a mess.

This is not a feature we're using internally so I would take guidance from the community here, we are open to suggestions. I don't think this was about errors specifically, I would suggest they might be best handled within the application itself.

In terms of aborting individual calls, this is something we might be able to look at, however, I am still thinking this is potentially overly complex and ultimately, all of the calls rely on one another, so if you were to abort the ReceiveMessageCommand, everything below that function would also fail.

I'm also unsure of a use case for aborting individual calls further down like deleting messages or changing visibility as that would cause future issues.