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

Define an error handling behavior of Serializer.SerializeBatch function #8830

Open
dialogbox opened this issue Feb 8, 2021 · 2 comments
Open
Labels
feature request Requests for new plugin and for new features to existing plugins help wanted Request for community participation, code, contribution size/l 1 week or more effort

Comments

@dialogbox
Copy link
Contributor

Feature Request

Currently, the serializer interface doesn't define error handling behavior of SerializeBatch function.

If an error is occurred in the middle of processing multiple metrics, whether of not return the rest of succeeded metrics is up to the implementation.

Proposal:

Define the expected behaviour and add it in the comment/document.

Current behavior:

Undefined.

It made each serializer uses different strategy.

For example,

Desired behavior:

Having well defined set of behavior including

  • Whether of not stop processing all the metrics if error occurs from one of the metrics
  • Whether of not log the error if we ignore the error
    • Maybe we can change the return error type to []error
  • Possibly having a config flag for changing the behavior

Use case:

This is important to reduce possible confusions of end users and plugin writers.

@dialogbox dialogbox added the feature request Requests for new plugin and for new features to existing plugins label Feb 8, 2021
@powersj
Copy link
Contributor

powersj commented Mar 31, 2022

next steps: review how this might look if we want to adopt this

@srebhan you had a conversation about this in #8828, did you have thoughts here?

@powersj powersj added the help wanted Request for community participation, code, contribution label Mar 31, 2022
@srebhan
Copy link
Member

srebhan commented Apr 28, 2022

@powersj I think that having inconsistent behavior is not a good thing. Furthermore, a serializer might decide to just drop the complete batch resulting in throwing away more data than needed. So I tend to agree that we should define what the behavior is and allow a way to only drop the faulty parts if possible.
The same problem might also arise in parsers where you maybe can parse certain information (e.g. from an array or a bunch of text-lines) even-though there is an error elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requests for new plugin and for new features to existing plugins help wanted Request for community participation, code, contribution size/l 1 week or more effort
Projects
None yet
Development

No branches or pull requests

4 participants