[Host] Consumer error response per transport (#356)

[EtherZa]

@zarusz I was thinking about how to cleanly implement the message header feature (#359) which had me re-evaluate how the Abandon (#356) was implemented.

Abandon is only possible when using ASB and RabbitMQ, but other (future) transports may have their own requirements. As such, having an Abandon response in the ProcessResult enum was probably a little heavy handed. I have refactored the code to rather make use of specialized types to differentiate between available responses (and hopefully make the action more clear). In this way, each provider can now support the base responses (Failure, Success, SuccessWithResponse and Retry) while also adding speciailized support fot the anything available to the transport eg. DeadLetter (previously Abandon) or Failure(IDictionary<string, object> headers) for ASB. (Failure(...) has not been added in this PR, but is an example that should now be trivial to add).

RabbitMq looses Abandon but gains Requeue with the configuration option no longer being required.

Thoughts?

[EtherZa]

@zarusz Tests Amazon SQS are failing.

Queue SMB_638714009108838766_BasicQueue has unknown URL at this point. Ensure the queue exists in Amazon SQS.

[zarusz]

The flakiness observed in the build (e.g., Queue SMB_638714009108838766_BasicQueue has unknown URL at this point) might simply require retrying the build or force-pushing to re-trigger it. The int test seems flaky.

Yes, each transport does it in its own way, so part of me thought that adding extension methods on IConsumerContext to perform transport specific logic would be the most versatile way (like we have .Ack()/.Nack() for Rabbit).

As for the ASB headers, it would be good to also allow to set the headers in the regular IConsumer, as the message processing is being performed. The benefit here is that in case of a transient timeout on SQL it would return and one could just have the state restored with next retry (in headers). In one of my projects we have consumers that adapt some downstream system and create a bunch of entities in external systems.

I am writing this comment without reviewing this PR yet, will try to do so soon.

[zarusz]

@EtherZa I've reviewed the PR, and this second iteration looks much cleaner. It effectively allows us to define transport-specific response actions. I'm happy to merge it once the build successfully completes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
80.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[EtherZa]

@EtherZa I've reviewed the PR, and this second iteration looks much cleaner. It effectively allows us to define transport-specific response actions. I'm happy to merge it once the build successfully completes.

Success!