API to modify/remove an existing entry from LogRecord attributes

[lalitb]

Fixes #1986

Changes

This PR adds two new methods, update_attribute and delete_attribute, to the public API of the LogRecord struct.

pub fn update_attribute(&Key, &AnyValue) -> Option<AnyValue>

• Updates the value of the first occurrence of an attribute with the specified key.
• If the attribute already exists, its value is replaced, and the old value is returned.
• If the attribute is not found, it is added as a new key-value pair, and None is returned.

pub fn remove_attribute(&mut self, key: &Key) -> usize

• Removes all the occurrence of attributes with the specified key.
• The count of deleted attributes is returned .

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

Attention: Patch coverage is 94.71366% with 12 lines in your changes missing coverage. Please review.

Project coverage is 77.0%. Comparing base (f911ed5) to head (d67da9f).

Files with missing lines	Patch %	Lines
opentelemetry-sdk/src/growable_array.rs	92.1%	9 Missing ⚠️
opentelemetry-sdk/src/logs/log_processor.rs	94.5%	3 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #2103     +/-   ##
=======================================
+ Coverage   76.9%   77.0%   +0.1%     
=======================================
  Files        122     122             
  Lines      22213   22439    +226     
=======================================
+ Hits       17082   17296    +214     
- Misses      5131    5143     +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cijothomas]

why ref, and not owned value?

[lalitb]

Good point. Have made it owned now.

[cijothomas]

should it delete all occurrences instead of first? I understand that we don't de-dup, so if a user believes they accidentally put a PII/something into LogRecord, and if they ended up with duplicates too, the expectation when one calls delete is that that key/value is completely eliminated.

[lalitb]

I thought delete first provides flexibility, and can be called repeatedly to delete all. But thinking more, its difficult to find use-case where user would like to delete first entry. Have update it to delete all occurrences. Also renamed it to remove_attribute, to be consistent with remove method of Vector and HashMap.

[cijothomas]

(I was thinking purely from the perspective of a app owner who realized that some PII/other things got leaked into Logs. For large codebases, it maybe hard to track down the producer of that, so people usually opt for a LogRecordProcessor to "delete" that as a mitigation! And they would be surprised if the delete didn't delete all occurrences, unless they kept calling it in a loop until no longer exists..)

[TommyCpp]

Small nit on code style

maybe easier to read if we do

match self
            .attributes
            .iter_mut()
            .find(|opt| opt.as_ref().map(|(k, _)| k == key).unwrap_or(false)) {
                     Some(attr) => {
                               // Take the old value and update the attribute
                               let old_value = attr.take().map(|(_, v)| v);
                               *attr = Some((key.clone(), value));
                               old_value
                        }
                     None => self.add_attribute(key.clone(), value.clone());
}

[TommyCpp]

I was little confused why we need to add_attribute regardless until I see the early return

[TommyCpp]

Or you have already tried that and compiler complains because the we are still holding mutable reference to self when iterator found nothing?

Techiniqually if we returned None, by that point the mutable reference to self should be dropped, allowing us to call add_attribute. But not sure if the refernece checker is smart enough

[lalitb]

Or you have already tried that and compiler complains because the we are still holding mutable reference to self when iterator found nothing?

@TommyCpp yes, i initially tried that approach, and got the error for still holding the mutable reference to self. Looks like the borrow checker is bit conservative and doesn't automatically drop iterators/temporaries until the end of the scope where they are used.

[cijothomas]

This is important, but trying to wrap up critical metric stuff/internal logging for the upcoming release, and will get back to this right after that.