Customizable error response handling (custom nacks) #177

Merged
merged 2 commits into from Nov 8, 2015

Conversation

Projects
None yet
2 participants
@dkastner
Contributor

dkastner commented Oct 18, 2015

Code related to #165

By default a nack is always sent on an exception.

Allows configuring custom handlers similar to the way logging is configured:

class Requeue
  def handle(delivery_info, properties, broker, e)
    if e.is_a?(Net::HTTPRetriableError) && !delivery_info.redelivered
      broker.requeue delivery_info.delivery_tag
      true
    else
      # Pass and let default nack handler nack the message
      false
    end
  end
end

Hutch::Config.set :error_acknowledgements, [
  Requeue.new
]
@@ -129,11 +130,23 @@ def handle_error(message_id, payload, consumer, ex)
end
end
+ def acknowledge_error(delivery_info, properties, broker, ex)
+ acks = error_acknowledgements +
+ [Hutch::Acknowledgements::NackOnAllFailures.new]

This comment has been minimized.

@michaelklishin

michaelklishin Oct 18, 2015

Collaborator

Why not simply have a non-empty default for error_acknowledgements?

@michaelklishin

michaelklishin Oct 18, 2015

Collaborator

Why not simply have a non-empty default for error_acknowledgements?

This comment has been minimized.

@michaelklishin

michaelklishin Nov 8, 2015

Collaborator

Answering my own question: because :error_acknowldgements is not a list, it's a chain of responsibility. Why so? Because double-acking would result in a channel exception and make underlying channel useless.

@michaelklishin

michaelklishin Nov 8, 2015

Collaborator

Answering my own question: because :error_acknowldgements is not a list, it's a chain of responsibility. Why so? Because double-acking would result in a channel exception and make underlying channel useless.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Oct 18, 2015

Collaborator

The overall idea is sound. However, I find the way you fall back to the default a bit odd. Once that is addressed, I think we can move forward with this. Thank you!

Collaborator

michaelklishin commented Oct 18, 2015

The overall idea is sound. However, I find the way you fall back to the default a bit odd. Once that is addressed, I think we can move forward with this. Thank you!

+ class NackOnAllFailures
+ include Logging
+
+ def handle(delivery_info, properties, broker, ex)

This comment has been minimized.

@michaelklishin

michaelklishin Nov 8, 2015

Collaborator

Since the interface here is a single function, it makes more sense to use call so that functions (blocks, procs, etc) can be used as well.

@michaelklishin

michaelklishin Nov 8, 2015

Collaborator

Since the interface here is a single function, it makes more sense to use call so that functions (blocks, procs, etc) can be used as well.

This comment has been minimized.

@michaelklishin

michaelklishin Nov 8, 2015

Collaborator

Scratch the above. It would lead to inconsistency with error handlers, which use handle and it is way too late to change that.

@michaelklishin

michaelklishin Nov 8, 2015

Collaborator

Scratch the above. It would lead to inconsistency with error handlers, which use handle and it is way too late to change that.

@michaelklishin michaelklishin merged commit e9e3a1f into gocardless:master Nov 8, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Nov 8, 2015

Collaborator

@dkastner merged with some minor tweaks. Thank you!

Collaborator

michaelklishin commented Nov 8, 2015

@dkastner merged with some minor tweaks. Thank you!

@dkastner

This comment has been minimized.

Show comment
Hide comment
@dkastner

dkastner Nov 8, 2015

Contributor

Thanks for taking a look!

Contributor

dkastner commented Nov 8, 2015

Thanks for taking a look!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment