Skip to content
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

[pkg/stanza] Use HandleEntryError for error handling #35758

Closed
wants to merge 24 commits into from

Conversation

khushijain21
Copy link
Contributor

Link to tracking issue

Fixes #35726

Uses HandleEntryError method to handle errors. More reasoning here

@khushijain21 khushijain21 requested review from djaglowski and a team as code owners October 12, 2024 16:36
Copy link
Member

@ChrsMark ChrsMark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add some basic unit testing for this to ensure that the "mute" logic is preserved in the future?

Also I believe we should have a change-log entry (bug fix probably) for this since it affects what users see.

@djaglowski
Copy link
Member

The API for parsers is a bit under-constrained but I think it would be cleaner to follow the pattern used in other parsers, where they move the parsing logic into an unexported function and then call that function using ProcessWith. This effectively applies the error handling to any errors returned. Example

@ChrsMark
Copy link
Member

We already pass the parse method to the ParseWith and ProcessWithCallback :

However the problem here is that we had to parse time after these calls in a custom func to avoid having to redefine the time Parser for each runtime. That's because the time parser is called after the parse function is called:

timeParseErr = p.TimeParser.Parse(entry)

@djaglowski
Copy link
Member

Sure, but can't we push all parsing functionality into a single call to ProcessWith?

@ChrsMark
Copy link
Member

ChrsMark commented Oct 14, 2024

Hmm I think ProcessWith will still end up calling just ParseWith in which the time parsing (with the time.Parser) will happen after the custom parse is called.

However, I think we can do the rest of the custom time parsing etc in a callback function which will be passed to ProcessWithCallback.

@djaglowski
Copy link
Member

Thanks for taking another look @ChrsMark. I'm a bit rusty on this part of the API so my suggestions are a bit off, but intuitively there must be a more normalized way than applying a special wrapper to every return err.

@khushijain21 khushijain21 requested a review from ChrsMark October 15, 2024 06:56
@ChrsMark
Copy link
Member

but intuitively there must be a more normalized way than applying a special wrapper to every return err

@djaglowski agreed! I think we can achieve this by moving the extra logic in a callback function passed to ProcessWithCallback. Do you see any possible issue with that?

@khushijain21
Copy link
Contributor Author

Hello, following the conversation, will this require code refactoring to avoid additional wrapper around each err? And if yes, can you direct how so?

@ChrsMark
Copy link
Member

ChrsMark commented Oct 16, 2024

Hey @khushijain21 I believe my proposal would worth giving it a try. Unless @djaglowski has a different view.

My proposal would be to move any additional logic that can produce unhandled errors into a callback function and then pass this function to ProcessWithCallback replacing with that the ProcessWith calls.

In this, the ProcessWithCallback will handle any errors produced by the callback function.

Note that ProcessWithCallback is already used at

err = p.ParserOperator.ProcessWithCallback(ctx, entry, p.parseDocker, p.handleAttributeMappings)
so this will also need to change so as the passed callback to also include the time parsing etc.

Let me know if that makes sense.

@djaglowski
Copy link
Member

@ChrsMark, thanks, I think what you suggest makes sense.

@khushijain21 khushijain21 requested a review from ChrsMark October 23, 2024 04:30
khushijain21 and others added 4 commits October 23, 2024 13:29
Co-authored-by: Christos Markou <chrismarkou92@gmail.com>
Co-authored-by: Christos Markou <chrismarkou92@gmail.com>
@khushijain21 khushijain21 requested a review from ChrsMark October 23, 2024 12:46
TylerHelmuth pushed a commit that referenced this pull request Oct 23, 2024
…llback (#35769)

<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description

Out of the discussions at
#35758
I realized that `ProcessWithCallback` does not handle the error returned
by the callback function. Since the error of the parse function is
handled I think we should handle this of the callback too.

<!-- Issue number (e.g. #1234) or full URL to issue, if applicable. -->
#### Link to tracking issue
Fixes

<!--Describe what testing was performed and which tests were added.-->
#### Testing

<!--Describe the documentation added.-->
#### Documentation

<!--Please delete paragraphs that you did not use before submitting.-->

---------

Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
@khushijain21
Copy link
Contributor Author

@ChrsMark any update?

@ChrsMark
Copy link
Member

Unit tests are failing now. I think that's because of the change in HandleEntryError from #35834.

Copy link
Member

@ChrsMark ChrsMark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After #35834 I think that what we have discussed here changes a little bit. I have commented back on the issue as I think we need to revisit the approach.

}

if err = p.ParseWith(ctx, entry, parse); err != nil {
if p.OnError == DropOnErrorQuiet || p.OnError == SendOnErrorQuiet {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we should discard the error here. This could lead to duplicating entries as described at #35973.

Otherwise, the container parser will get no error back and will further move the entry to the recombine parser.

if err != nil {
return fmt.Errorf("failed to parse containerd log: %w", err)
return p.HandleEntryError(ctx, entry, stanzaerr.Wrap(err, "containerd log"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the error already handled inside the ParseWithCallback? I would assume we should return nil here as the entry has already been either moved forward or dropped.

djaglowski pushed a commit that referenced this pull request Nov 7, 2024
…ds (#36213)

<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description

This issue was caught at
#35758.
This PR ensures that time parsing happens before the entry is sent to
the next operator in the pipeline.

<!-- Issue number (e.g. #1234) or full URL to issue, if applicable. -->
#### Link to tracking issue
Fixes ~

<!--Describe what testing was performed and which tests were added.-->
#### Testing
Added

<!--Describe the documentation added.-->
#### Documentation
~

<!--Please delete paragraphs that you did not use before submitting.-->

Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
Copy link
Contributor

This PR was marked stale due to lack of activity. It will be closed in 14 days.

@github-actions github-actions bot added the Stale label Nov 14, 2024
sbylica-splunk pushed a commit to sbylica-splunk/opentelemetry-collector-contrib that referenced this pull request Dec 17, 2024
…llback (open-telemetry#35769)

<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description

Out of the discussions at
open-telemetry#35758
I realized that `ProcessWithCallback` does not handle the error returned
by the callback function. Since the error of the parse function is
handled I think we should handle this of the callback too.

<!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. -->
#### Link to tracking issue
Fixes

<!--Describe what testing was performed and which tests were added.-->
#### Testing

<!--Describe the documentation added.-->
#### Documentation

<!--Please delete paragraphs that you did not use before submitting.-->

---------

Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
sbylica-splunk pushed a commit to sbylica-splunk/opentelemetry-collector-contrib that referenced this pull request Dec 17, 2024
…ds (open-telemetry#36213)

<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description

This issue was caught at
open-telemetry#35758.
This PR ensures that time parsing happens before the entry is sent to
the next operator in the pipeline.

<!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. -->
#### Link to tracking issue
Fixes ~

<!--Describe what testing was performed and which tests were added.-->
#### Testing
Added

<!--Describe the documentation added.-->
#### Documentation
~

<!--Please delete paragraphs that you did not use before submitting.-->

Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

send_quiet is not working for container operator
4 participants