Added support for Lettuce reactive Redis commands

[wuwen5]

• If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
• Update the CHANGES log.

Resolves apache/skywalking#12817

[wu-sheng]

I am not sure whethere there is some issues in e2e. Many fails, but seem irrelevant.

[wu-sheng]

I fixed the test framework via recent release PR(#791). Although two rocketmq cases have to been removed as it can't pass in CI in anyway, can't find out a clue.

Once I get that PR merged, I could update here, and your case should be able to run again.

[wu-sheng]

Resolve conflicts as I put 9.7 out, and have fixed all things.

[wu-sheng]

supported-framework doc should be updated as well, and supported versions should be in changes as well.

[wu-sheng]

A key question is as following, we should consider this case. I think user could use like this, right?
Reactor-only context source: The snapshot is extracted via SKYWALKING_CONTEXT_SNAPSHOT from Reactor Context, which is only set by the spring-webflux plugin. If someone uses
Lettuce reactive without Spring WebFlux (e.g., standalone Reactor app), no context propagation occurs.

[wuwen5]

supported-framework doc should be updated as well, and supported versions should be in changes as well.

This PR does not change the supported version ranges of any frameworks

[wu-sheng]

A key question is as following, we should consider this case. I think user could use like this, right?

**Reactor-only context source: The snapshot is extracted via SKYWALKING_CONTEXT_SNAPSHOT from Reactor Context, which is only set by the spring-webflux plugin. If someone uses

Lettuce reactive without Spring WebFlux (e.g., standalone Reactor app), no context propagation occurs.**

How about this?

[wuwen5]

A key question is as following, we should consider this case. I think user could use like this, right?
Reactor-only context source: The snapshot is extracted via SKYWALKING_CONTEXT_SNAPSHOT from Reactor Context, which is only set by the spring-webflux plugin. If someone uses
Lettuce reactive without Spring WebFlux (e.g., standalone Reactor app), no context propagation occurs.

How about this?

I'm still working on the changes and verifying them.

[wu-sheng]

I saw you added some propogation logic, but only when isActive. But is there a chance there is no previous context created? such as no SpringMVC ahead of this. Still nothing will be captured.

[wuwen5]

I saw you added some propogation logic, but only when isActive. But is there a chance there is no previous context created? such as no SpringMVC ahead of this. Still nothing will be captured.

I personally think we should not create a new context when isActive() is false，This component is essentially an exit instrumentation, whose responsibility is to capture and propagate an existing context rather than to create one. In the SkyWalking tracing model, the decision to start a trace should be made by upstream components (such as WebFlux, WebMVC, scheduled jobs, etc.), not by downstream exit components.

This is also consistent with the execution model of Redis synchronous commands, where exit spans are not forcibly correlated with each other when there is no active upstream context, and each span remains independent.

[wu-sheng]

I am not sure about general redis plugin, but for project level consideration, there is no pre condition requiring an entry span start a redis access.

[wuwen5]

there is no pre condition requiring an entry span start a redis access.

Sure, that’s correct. My earlier description was indeed incorrect.
What I intended to convey is that currently, multiple exit spans may each start their own independent traces, but they cannot correlate with one another—they remain isolated. To properly link them, an external (parent) span is needed. However, I haven't yet found a suitable injection point to establish this correlation. At the very least, creating a local span at the current !isActive() location doesn't resolve the issue.

I've found that it seems difficult to achieve this solely within the Lettuce-plugin; it requires an outer-layer interception.

However, users can a toolkit to achieve this correlation, for instance by manually creating and injecting a parent span.

e.g.

Tracer.createLocalSpan("UserReactiveLocalSpan");
        Mono<String> result = reactiveCommands.get("key")
                .then(Flux.concat(
                        reactiveCommands.set("key0", "value0"),
                        reactiveCommands.set("key1", "value1")
                ).then())
                .thenReturn("Success");
        result.block();
        Tracer.stopSpan();

[wu-sheng]

My point is, it is user responsibility, if spans(exit) are separated with different trace IDs, so be it. User could add codes like you mentioned to link them if they want, but they need to see those spans.

[wu-sheng]

You should just release the limitation of creating a span. If there is no main span, let's create several independent spans for lettuce accessing.