-
-
Notifications
You must be signed in to change notification settings - Fork 56
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
ref(eap-mutations): Implement synchronizer #6436
base: master
Are you sure you want to change the base?
Conversation
Induce a hardcoded delay so that the eap-mutations consumer will always lag behind the eap-spans consumer. This PR (and most of my work on the mutations consumer) makes a point to not use custom strategies, as that's too much boilerplate. Rather, we should improve the arroyo API. For this PR, this arroyo PR is necessary: getsentry/arroyo#388
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.
Question: presumably this is going to cause a bunch of errors to get thrown, at least when it is first deployed, since none of the messages coming in currently have been delayed.
Is there a concern with that at all? Or is it just something that will blip for a bit and then stabilize?
those errors are not logged, just causing backpressure (paused state in arroyo) arroyo will emit a warning at most every 5 seconds for when the consumer is seeing an abnormal/constant amount of backpressure, so that might cause some noise in sentry. but we already have an issue for that, so it should group nicely. |
@@ -97,6 +101,12 @@ impl ProcessingStrategyFactory<KafkaPayload> for MutConsumerStrategyFactory { | |||
Some("parse"), | |||
); | |||
|
|||
let mut synchronizer = Synchronizer { | |||
min_delay: TimeDelta::days(1), |
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.
Any reason why we specifically chose 1 day here?
Induce a hardcoded delay so that the eap-mutations consumer will always
lag behind the eap-spans consumer.
This PR (and most of my work on the mutations consumer) makes a point to not use custom strategies, as that's too much
boilerplate. Rather, we should improve the arroyo API. For this PR, this
arroyo PR is necessary: getsentry/arroyo#388