-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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(post-process-forwarder) Different errors and transaction forwarders #28954
Conversation
Added different Errors and Transactions post process forwarders. The errors one handles backward compatibility use case as well where the kafka header might be missing. These new classes aren't going to be used right now. They will be integrated in a different PR.
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.
I don't think you need to use mocks for the Message objects in your tests. Other than that no issue with this.
forwarder = PostProcessForwarderWorker(concurrency=1) | ||
@pytest.fixture | ||
def kafka_message_without_transaction_header(kafka_message_payload): | ||
mock_message = Mock() |
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.
Why using a mock for the message? Can't we just create a real Message object ?
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.
I tried using actual confluent_kafka.Message but it does not work. For example the set_headers expect Message objects rather than the actual headers. When I create a Message and pass it to set_headers, it barfs saying "cannot create 'cimpl.Message' instances".
I feel its fine to use mocks here, since they return values which would have been returned by the actual message when the api's like headers(), values() are called.
…rwarders (#29225) In feat(post-process-forwarder) Different errors and transaction forwarders #28954, we created different processing strategies for errors and transactions post process forwarders. In this PR, we enable post process forwarder to run with one of the following entities (errors, transactions, all) The all option would be used in scenarios where we don't need separate post process forwarders. Example devserver, single tenant. There is no production change with this code since the default option for entity is "all" which means the current post process forwarder would handle all messages
Added different Errors and Transactions post process forwarders. The
errors one handles backward compatibility use case as well where the
kafka header might be missing. These new classes aren't going to be
used right now. They will be integrated in a different PR.