go-grpc-compression seems to be abandoned

[iblancasa]

Component(s)

config/configgrpc

Describe the issue you're reporting

Library go-grpc-compression didn't release since Jun 2024. We have some dependency on it.

This ticket, for instance, that is causing some issues with zstd and memory allocations has some PRs opened but none of them were merged and released.

What should we do in these cases? I can help maintaining a fork of the library if needed.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[axw]

Thanks for raising this @iblancasa.

I'd personally be inclined to move the decompressors that are currently in confighttp so they can be used used by configgrpc too, and remove a third-party dependency.

We need to implement https://pkg.go.dev/google.golang.org/grpc/encoding@v1.78.0#Compressor. In particular:

Decompress(r io.Reader) (io.Reader, error)

confighttp has a map of func(body io.ReadCloser) (io.ReadCloser, error) here:

opentelemetry-collector/config/confighttp/compression.go

Line 75 in 55399d4

var availableDecoders = map[string]func(body io.ReadCloser) (io.ReadCloser, error){

So it should be a matter of making that available to configgrpc, and then wrapping ReadClosers sothey close on EOF something like this:

type autoClosingReader struct {
    rc io.ReadCloser
}

func (a *autoClosingReader) Read(p []byte) (n int, err error) {
    if a.rc == nil {
        return 0, io.EOF
    }
    n, err = a.rc.Read(p)
    if err == io.EOF {
        a.rc = nil
    }
    return n, err
}

WDYT?

[dmathieu]

I agree with @axw that if we can't rely on that dependency anymore, we should internalize it rather than take on a new component's ownership.

Have you tried contacting the repository owner directly?
Maybe they'd be willing to share the maintainership burden (which is very different from forking)?

[iblancasa]

Have you tried contacting the repository owner directly? Maybe they'd be willing to share the maintainership burden (which is very different from forking)?

I created a PR and also commented in a couple of issues. Not answer at all.

I'm happy with the path @axw proposed. I can work on it if you agree :)