feat: Add new ProcessInlineWhileDraining option for the InlineReceiver#2347
Merged
jeremydmiller merged 1 commit intoJasperFx:mainfrom Mar 25, 2026
Merged
Conversation
When enabled, attempts processing messages already received instead of deferring them once the drain is started. This allows avoiding latency outliers from deferring messages behind ones received after it.
This was referenced Mar 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi again. This is a follow up to #2322. When I made that PR I misunderstood Defer as putting messages back to the front of the queue (though in hindsight putting it at the back makes more sense in most cases). Putting it at the back can lead to outliers in processing time (especially when put behind thousands of messages, or if the pod which picks up the message a second time starts draining itself), so I've added this option to attempt processing during the drain instead of deferring back to the queue.
It's an option instead of the default because I'm not sure if it's reasonable to do this for existing consumers, though a properly architected inline handler should handle it fine. The other alternative I thought of was the ability to defer to the front of the queue (eg. set sqs visibility timeout to 0), but that would be a much bigger changeset for each receiver type.