-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: SIGNAL-7060 preemtively drop large messages from queue #101
Merged
seungjinstord
merged 16 commits into
main
from
SIGNAL-7060-another-fix-for-large-message
Oct 1, 2024
Merged
Changes from all commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
b17f336
UPDATE: have send_message() drop large messages ahead of time
seungjinstord 72cf3da
UDPATE: adjust integration test based on new pre-dropping strategy
seungjinstord 3620b34
UPDATE: finally! raw snapshot of the fix
seungjinstord 1b3179d
Revert "UPDATE: finally! raw snapshot of the fix"
seungjinstord 1f4caa6
UPDATE: move the terminate related log to terminate()
seungjinstord 97a18fb
UPDATE: with IO.inspect
seungjinstord e6f8374
REMOVE: IO.inspect
seungjinstord fd0ec14
UPDATE: variable name
seungjinstord 158affc
Merge branch 'main' into SIGNAL-7060-another-fix-for-large-message
kinson 44f397b
UPDATE: make test less flaky
seungjinstord ada3f2e
ADD: more moduledoc
seungjinstord 95293aa
UPDATE: move test to where it should've been - in the queue testing s…
seungjinstord 37dbca6
UPDATE: fix typo
seungjinstord ab77335
ADD: missing reference
seungjinstord 294084f
Merge branch 'main' into SIGNAL-7060-another-fix-for-large-message
seungjinstord 02ec487
Merge branch 'main' into SIGNAL-7060-another-fix-for-large-message
seungjinstord File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make sure I understand, the primary change here is that before this pr, we would still attempt to publish messages that are too large unless the async worker process was terminating in which case we would filter them out.
Whereas, with this change we will pre-emptively drop the large messages and never try to publish them. Is that correct?
I think that makes sense from a functional perspective, but I want to double check my understanding before approving!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup that's 100% correct. Originally we would ignore the
state.max_request_bytes
on the first send attempt, and just push first, and then handle the errors bubbling up frombrod
.Adding to the context: due to increased traffic and size - we are observing
brod
's related processes failing and the AsyncWorker layer isn't getting the "raw" error messages with the actualy message payload (it seems brod is eating it ahead of bubbling up).Therefore the other way would be if we already know and have set the
state.max_request_byte
, we should be safe in filtering the large messges out ahead of time, so the queue won't even have them.