Chore: Fixes error handling in log exporter

[vanugrah]

PR Description

Which issue(s) this PR fixes

The error handling in log_exporter.go for the app_agent_receiver is currently implemented in a way that the err variable gets overridden - hence the only time it will return an error is if there is an issue processing the last event.

This PR addresses introduces error handling to return if any error is encountered during the processing of logs/measurements/exceptions/events by the logs_exporter.

Notes to the Reviewer

I'm not entirely sure what the thought process of the original author was - but my guess is they wanted to do all the processing and only return errors at the end. If that is the case, this PR should be modified to adhere to that intent.

PR Checklist

• CHANGELOG.md updated
• Documentation added
• Tests updated
• Config converters updated

[CLAassistant]

All committers have signed the CLA.

[mattdurham]

@domasx2 I want to double check this doesnt break anything for you all, this causes it to fail on the first exception instead of trying to process everything.

[domasx2]

Hey, sorry, missed the notification!
I think my original intent here was to continue handling items despite errors. These payloads are generally one shots that are not retried, so the thinking was to handle what we can and drop what we can't, w/o stopping on first failed item.

I'm gonna pass this to @rlankfo though for a look. Not sure how the cliend endpoint deals with this?

[mattdurham]

Based on @domasx2 comments, @vanugrah using the multierrors might be a better solution here. Lets you build an array of errors and then return. We use this library already in quite a few places.

[kminehart]

LGTM! I'd rather see these as if err := func(...); err != nil { but either way works. 👍

though let Robbie approve before merging I haven't worked in this repo yet.

Also +1 for the multierrors suggestion based on what others are saying. Seems like this does actually have maybe some unintended consequences so I'll withdraw my approval for now so others have a chance to look.

[rlankfo]

Based on @domasx2 comments, @vanugrah using the multierrors might be a better solution here. Lets you build an array of errors and then return. We use this library already in quite a few places.

I agree with @mattdurham that we should use multierror here. Currently, if exporting one item from the payload fails then it gets logged and the remaining items in the payload are still processed. With this change, we'll fail on the first error and drop remaining data that might have been otherwise successfully processed.

[vanugrah]

Hey folks - apologies for the delay. Totally support the use of multierrors. Will try to update this PR over the weekend.

[github-actions]

This PR has not had any activity in the past 30 days, so the needs-attention label has been added to it.
If you do not have enough time to follow up on this PR or you think it's no longer relevant, consider closing it.
The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your PR will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity.
Thank you for your contributions!

[github-actions]

This PR has not had any activity in the past 30 days, so the needs-attention label has been added to it.
If you do not have enough time to follow up on this PR or you think it's no longer relevant, consider closing it.
The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your PR will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity.
Thank you for your contributions!