why ref, and not owned value?

Good point. Have made it owned now.

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.

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.

(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..)

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());
}

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

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

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.