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

add support for additional decoders #7977

Merged

Conversation

codeboten
Copy link
Contributor

@codeboten codeboten commented Jun 27, 2023

This provides the ability to add support for compression types which are not supported in core, to be supported by individual components.

This change addresses an issue caused by #7927, which prevents receivers that use confighttp from adding support for their content-encoding types easily. They still can by implementing an error handler, but that seems messy.

An alternative to this PR is to not return an error for an unsupported encoding type as was the case before #7927

If the approach is acceptable, I will add the unit tests and changelog

@codeboten codeboten force-pushed the codeboten/add-option-for-decompressor branch from 1f1bfc5 to 2aece6b Compare June 27, 2023 20:51
@codeboten codeboten force-pushed the codeboten/add-option-for-decompressor branch from 2aece6b to 57dd104 Compare June 27, 2023 22:50
@codeboten codeboten marked this pull request as ready for review June 27, 2023 22:50
@codeboten codeboten requested review from a team and Aneurysm9 June 27, 2023 22:50
@codeboten codeboten force-pushed the codeboten/add-option-for-decompressor branch from 57dd104 to 5139a96 Compare June 27, 2023 22:53
@codecov
Copy link

codecov bot commented Jun 27, 2023

Codecov Report

Patch coverage: 94.00% and project coverage change: +0.05 🎉

Comparison is base (8278824) 90.90% compared to head (abf444a) 90.96%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #7977      +/-   ##
==========================================
+ Coverage   90.90%   90.96%   +0.05%     
==========================================
  Files         300      300              
  Lines       15074    15090      +16     
==========================================
+ Hits        13703    13726      +23     
+ Misses       1097     1091       -6     
+ Partials      274      273       -1     
Impacted Files Coverage Δ
config/confighttp/compression.go 84.00% <93.02%> (+1.77%) ⬆️
config/confighttp/confighttp.go 92.17% <100.00%> (+4.31%) ⬆️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@tigrannajaryan
Copy link
Member

An alternative to this PR is to not return an error for an unsupported encoding type as was the case before #7927

I think reverting to the wrong behavior is probably not what we want. Let's go forward with your PR. The question I have is whether there is a need for custom decoders or we just need to add "snappy" for all?

@codeboten
Copy link
Contributor Author

I think reverting to the wrong behavior is probably not what we want. Let's go forward with your PR. The question I have is whether there is a need for custom decoders or we just need to add "snappy" for all?

Adding snappy would address the one case failing in contrib at the moment. I've not looked for additional cases, though @jpkrohling pointed out in a DM that this would allow anyone wanting to offer alternative decoders even for supported encodings could do so w/ this functionality

@codeboten codeboten force-pushed the codeboten/add-option-for-decompressor branch 3 times, most recently from b6bd232 to 01ec534 Compare June 28, 2023 16:16
This provides the ability to add support for compression types which are
not supported in core, to be supported by individual components.

Signed-off-by: Alex Boten <aboten@lightstep.com>
@codeboten codeboten force-pushed the codeboten/add-option-for-decompressor branch from 01ec534 to abf444a Compare June 28, 2023 16:36
Copy link
Member

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

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

Looks good to me, but I would love to have another test for snappy.

},
},
}
d.decoders["deflate"] = d.decoders["zlib"]
Copy link
Member

Choose a reason for hiding this comment

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

Would it be asking too much to add an explicit test for snappy, as this is the one failing for existing receivers?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could add one, but it would essentially be a duplicate of the "UnsupportedCompression" test here:

name: "UnsupportedCompression",
encoding: "nosuchcompression",
reqBody: bytes.NewBuffer(testBody),
respCode: http.StatusBadRequest,
respBody: "unsupported Content-Encoding: nosuchcompression\n",

Copy link
Member

Choose a reason for hiding this comment

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

My idea is that it would replace the "custom-encoding" test case with a real implementation, and it would be converted into a test that overrides an existing encoding once snappy is added. In any case, this isn't a blocker.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll add this in a follow up PR since this is blocking contrib :)

@codeboten codeboten merged commit c3f70bd into open-telemetry:main Jun 29, 2023
@codeboten codeboten deleted the codeboten/add-option-for-decompressor branch June 29, 2023 14:46
@github-actions github-actions bot added this to the next release milestone Jun 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants