-
Notifications
You must be signed in to change notification settings - Fork 93
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(replay): separate feedback from attachments in the same envelope #3403
Conversation
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.
Please see if you can add some tests or modify existing tests (if there are any, why didn't they break with that change?).
Also before moving on with this to SaaS it'd be best if you figured out the wire format for the Feedback topic, it's better to avoid supporting multiple formats on the other "end".
…/separate-feedback-from-attachments2
Thanks for the review! Could you elaborate what you mean by "wire format"? Do you mean the You're right, I'll make a ticket for adding that message type and remove it from this PR, it's something I forgot to clean that up. After adding coverage I could deploy this with a FF enabled for s4s only. |
Yes, you're using the |
Got it, I'll definitely look into it and give it more thought before finalizing this PR. Thanks for the suggestion! |
…/separate-feedback-from-attachments2
… envelope (#69351) Needed for getsentry/relay#3403 For relay, using an option is way simpler than a FF. This option will also be used to test separating the logic for producing feedbacks (`user_report_v2`'s in `store.rs`)
I've decided to hold off on making a UserReportV2KafkaMessage type until the new topic/infra has been deployed to all regions in prod. It adds an extra layer of complexity and testing that will delay this feature, which the SDK team needs to GA user feedback in ~1 week. It probably shouldn't be done until we write a separate ingest strategy for the feedback consumer (right now it shares this with events). |
relay-server/src/services/store.rs
Outdated
@@ -189,13 +189,15 @@ impl StoreService { | |||
let retention = envelope.retention(); | |||
let event_id = envelope.event_id(); | |||
|
|||
let use_feedback_ingest_v2 = self.global_config.current().options.feedback_ingest_v2; |
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.
not sure what this naming implies, maybe just separate_attachments_from_feedback
?
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.
Decided to name it this because it also results in some code restructuring / different code path for producing feedback in StoreService.
I agree the naming's a little funky though, will sleep on it + see what Vienna thinks?
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 would also prefer aligning the variable name (and the field name feedback_ingest_v2
) with either the feature name ("inline attachments") or renaming it to describe what it actually enables.
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.
The flag's docs say it's temporary. Is it only used for testing in development or should we update the docs?
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.
It's used like a feature flag - we'll set it to true in test region(s), test the SDK, and remove this logic + non-v2 code path once satisfied. The flag is just to quickly "revert" in case things start to break
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.
What did you have in mind for updating the docs?
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.
other than the small nits / naming, lgtm
item: &Item, | ||
remote_addr: Option<String>, | ||
) -> Result<(), StoreError> { | ||
// check rollout rate option (effectively a FF) to determine whether to produce to new infra |
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.
See #3344
relay-server/src/services/store.rs
Outdated
@@ -189,13 +189,15 @@ impl StoreService { | |||
let retention = envelope.retention(); | |||
let event_id = envelope.event_id(); | |||
|
|||
let use_feedback_ingest_v2 = self.global_config.current().options.feedback_ingest_v2; |
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 would also prefer aligning the variable name (and the field name feedback_ingest_v2
) with either the feature name ("inline attachments") or renaming it to describe what it actually enables.
relay-server/src/services/store.rs
Outdated
ItemType::UserReportV2 => { | ||
if use_feedback_ingest_v2 { |
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.
With this, you can make sure that there's an error
log if there's an unexpected feedback item in the envelope.
ItemType::UserReportV2 => { | |
if use_feedback_ingest_v2 { | |
ItemType::UserReportV2 if use_feedback_ingest_v2 => { |
let topic = if is_rolled_out(organization_id, feedback_ingest_topic_rollout_rate) { | ||
KafkaTopic::Feedback | ||
} else { | ||
KafkaTopic::Events | ||
}; |
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.
Out of scope for this PR, but should we hard-code this to Feedback
soon? Or are some installations not ready for that yet? (self-hosted, devenv, ...)
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.
Yes this has to do with ops deployment of the feedback topic -- right now, its only in s4s and not other regions. This check and rollout rate will eventually be removed too
tests/.idea/workspace.xml
Outdated
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.
Did you check this in on purpose?
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.
No 😅
tests/integration/test_feedback.py
Outdated
if use_feedback_topic: | ||
mini_sentry.set_global_config_option("feedback.ingest-topic.rollout-rate", 1.0) | ||
feedback_consumer_ = feedback_consumer(timeout=20) | ||
other_consumer_ = events_consumer(timeout=20) |
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 the _
suffix?
relay-server/src/services/store.rs
Outdated
@@ -189,13 +189,15 @@ impl StoreService { | |||
let retention = envelope.retention(); | |||
let event_id = envelope.event_id(); | |||
|
|||
let use_feedback_ingest_v2 = self.global_config.current().options.feedback_ingest_v2; |
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.
The flag's docs say it's temporary. Is it only used for testing in development or should we update the docs?
… envelope (#69351) Needed for getsentry/relay#3403 For relay, using an option is way simpler than a FF. This option will also be used to test separating the logic for producing feedbacks (`user_report_v2`'s in `store.rs`)
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.
LGTM! Please see comments below before merging.
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.
Please, remove this file.
/// Flag for handling feedback and attachments in the same envelope. Temporary FF for fast-revert | ||
/// (will remove after user feedback GA release). |
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.
Without context, this comment is not clear to me what the flag should do. What do you think about something like the following?
/// Flag for handling feedback and attachments in the same envelope. Temporary FF for fast-revert | |
/// (will remove after user feedback GA release). | |
/// Kill switch to stop producing feedback items separately into Kafka. The topic is controlled by `feedback_ingest_topic_rollout_rate`. |
@aliu3ntry please address the suggestions above, I didn't realize the PR had auto-merging enabled. |
Oops, sorry! Reopened at #3486 @iker-barriocanal |
The idea is to restructure the code so that UserReportV2's don't end up in the catch-all extract_kafka_messages at the bottom of
store_envelope
, with attachmentsRelates to https://github.com/getsentry/team-replay/issues/393