fix(redisotel): fix the situation of reporting spans multiple times

[flc1125]

[ndyakov]

Hello, @flc1125, thanks for contributing. Would you mind describing the issue that you are trying to fix in more details:

• Why was this hook not needed?
• Why was it introduced initially?
• Is there a possibility this change breaks something?

And please add some tests if possible.

[flc1125]

Hello, @flc1125, thanks for contributing. Would you mind describing the issue that you are trying to fix in more details:

• Why was this hook not needed?
• Why was it introduced initially?
• Is there a possibility this change breaks something?

And please add some tests if possible.

OK, I am on vacation, I will deal with this issue when I have free time.

[flc1125]

@ndyakov When I was solving this problem, I found that some dependent packages would be automatically upgraded. That is to say, this PR, see if it can be prioritized. #3265

[flc1125]

Additionally, as a supplementary inquiry, I would like to understand the following information:

1. Currently, both the Go version and the dependency versions in this package are quite outdated. Do we have any requirements or limitations regarding the minimum supported version of Go? For example, upgrading to 1.22 or higher.

2. Can we use the following in the project: github.com/stretchr/testify

[ndyakov]

Additionally, as a supplementary inquiry, I would like to understand the following information:

1. Currently, both the Go version and the dependency versions in this package are quite outdated. Do we have any requirements or limitations regarding the minimum supported version of Go? For example, upgrading to 1.22 or higher.

I am on the same boat as you and still trying to figure out if we have any blockers to upgrade to a newer Go version. I do think @monkey92t or @vmihailenco can share if they need this library to keep 1.18 as a minimum go version.

2. Can we use the following in the project: github.com/stretchr/testify

No need to add another assert library, we do use a fork of https://onsi.github.io/gomega/ and I hope to soon actually have the official https://onsi.github.io/gomega/ . Both questions are kind of related, if we are fine to update the go version we may try to move to the official https://onsi.github.io/gomega/ and https://onsi.github.io/ginkgo/ libraries.

[ndyakov]

@ndyakov When I was solving this problem, I found that some dependent packages would be automatically upgraded. That is to say, this PR, see if it can be prioritized. #3265

I still don't understand how and why this issue occurred. Does removing the hooks break anything else or is it a safe fix. Again, maybe @monkey92t has more experience with the otel codebaase in go-redis.

[flc1125]

@ndyakov When I was solving this problem, I found that some dependent packages would be automatically upgraded. That is to say, this PR, see if it can be prioritized. #3265

I still don't understand how and why this issue occurred. Does removing the hooks break anything else or is it a safe fix. Again, maybe @monkey92t has more experience with the otel codebaase in go-redis.

That's not the case, it's just an additional optimization. You can ignore this issue. 😄

[flc1125]

• Why was this hook not needed?

In the cluster architecture, when a Redis command is initiated, it will generate two spans of the link due to the repeated Hook. But I think one span should be enough actually.

• Why was it introduced initially?

I think I can't answer this question, maybe need to consult the author at that time.

This is an early PR: #2244

@vmihailenco Please help, and see if you can answer this question.

• Is there a possibility this change breaks something?

Since it cancelled a link, it is a disruptive change. But I think it might be a defect rather than a function. It should be fixed.

---

After the above conclusions are drawn, I will combine the results to conduct supplementary tests.