FEATURE: Improve the republish strategy with immediateNack and dead-letter queue about rascal

[cressie176]

Hi @apehead,

Thanks for the feature request. Unfortunately when you nack a message, you can't modify it. Hence it isn't possible to remove the immediateNack header. I'll leave the issue open and have a think about if there's an alternative approach that might work

[cressie176]

One option might be for Rascal to optionally ignore the immediateNack header based on a configurable timeout. This would allow the message to be republished until the attempts expired, then immediately nacked. Providing it sits on the DLQ for longer than the timeout, the message could be moved back to the work queue without removing the immediateNack headers. It's not perfect, but could still be useful

[cressie176]

A similar idea to explore is whether the x-death header could be used. E.g. immediateNack only works when the current number of x-death records is the same as when the message was republished with the immediateNack header.

[apehead]

@cressie176 thanks a ton for jumping in on this so quickly and offering up these ideas. Truly appreciated!

I've thought about the options you mentioned and they seem like good ideas.
I'm unsure which one offers greater control over message handling with less complexity for Rascal, so I trust your judgment.

I'm all in if you need a hand with testing or contributions.

[cressie176]

Hi @apehead,

I took a look at this over the weekend. I think the x-death header is the way to go...

The x-death header is updated automatically when a message is nacked. It holds an array of records similar to the following...

[
  {
    count: 3,
    exchange: '',
    queue: 'work_queue',
    reason: 'rejected',
    'routing-keys': [ 'work_queue' ],
    time: { '!': 'timestamp', value: 1715451949 }
  },
  {
    count: 1,
    exchange: '',
    queue: 'other_queue',
    reason: 'rejected',
    'routing-keys': [ 'other_queue' ],
    time: { '!': 'timestamp', value: 1715452131 }
  }  
]

The records in the array are keyed using the queue and reason fields, so repeated nacks for the same queue and reason will increment the count, rather than inserting a new record. When rascal rejects with an immediate nack, the reason is always "rejected".

Implementing this feature can be achieved by

1. copying the relevant count into a new header rascal.recovery.${queue}.rejected.count where rascal sets the immediateNack header (or defaulting it to zero) See here.
2. ignoring and deleting the immediateNack header when the message's relevant x-death count header is greater than the recovery count stored in (1). See here

I think implementation will be straightforward, but the tests slightly cumbersome. I would expect coverage for

1. No x-death header
2. x-death header less than recovery count
3. x-death header count equal to recovery count
4. x-death header greater than recovery count
5. ignores irrelevant x-death header

Added for both the callback and promise tests

I can't see a downside to this feature so I think it is worth changing the behaviour of the immediateNack option, rather than adding a new option. However the documentation will also need to be updated.

If you want to have a go, please do, otherwise I can probably get to it in the week.

[cressie176]

Available in [email protected]

[apehead]

Thanks for the quick fix @cressie176! I really appreciate your dedication.
Sorry I couldn't contribute this time, but if there's another chance in the future, I'd love to help.