-
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
fix(server): Forward-compatible AttachmentType #1638
Conversation
let breadcrumbs2 = envelope | ||
.take_item_by(|item| item.attachment_type() == Some(AttachmentType::Breadcrumbs)); | ||
.take_item_by(|item| item.attachment_type() == Some(&AttachmentType::Breadcrumbs)); |
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.
AttachmentType
is not Copy
anymore, because one of its variants now contains a String
.
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 are we adding an Unknown(String)
variant instead of a specific variant for the view hierarchy? Having a fallback unknown variant seems ok to me, but I wonder if it's the best solution for that specific case we're now trying to solve.
@iker-barriocanal we will add a specific variant for the view hierarchy in a different PR, so this PR actually won't help with the rollout of that new type. It only ensures that when we add attachment types in the future, envelopes will not be dropped by external Relays. |
As we did in #1246 for
ItemType
, add anUnknown(String)
variant toAttachmentType
. Whenaccept_unknown_items
is set to false, items with this attachment type will be dropped.This will allow outdated external Relays to forward new attachment types instead of dropping the entire envelope.
This defect was discovered in getsentry/rfcs#33, which introduces a new attachment type.