The suggested fix in #1645 improves propagation when kernel spans are filtered out by topic. This builds on that work. It would be useful if cppTango preserved the active trace context even when telemetry tracing is disabled. In that mode, cppTango should avoid emitting its own kernel spans, but nested calls and downstream code should still be able to remain as part of the incoming trace. Today, similar behaviour can already be achieved by keeping tracing enabled and removing all tracing endpoints. That preserves propagation without exporting spans. However, that is harder to configure than simply toggling the tracing flag. Desired behavior: - telemetry enabled + tracing disabled should still keep context propagation active - cppTango should not emit client/server kernel spans in that mode - nested client calls should continue on the same trace This would make the tracing-disabled behaviour more consistent with the propagation-first model introduced by #1645. And with the work already done in PyTango https://gitlab.com/tango-controls/pytango/-/merge_requests/993. The attached patch, `02-cpptango-telemetry-tracing.patch`, is one implementation of that behaviour and includes focused Catch2 coverage for the tracing-disabled cases. We also attach the previous patch, `01-cpptango-telemetry-topics.patch`, which is required before this one (starting at cppTango tag 10.3.0) I.e., cpptango 10.3.0, apply 01-cpptango-telemetry-topics.patch, apply 02-cpptango-telemetry-tracing.patch - [01-cpptango-telemetry-topics.patch](/uploads/6af0e258cbbe2ecae0cce207327e69d5/01-cpptango-telemetry-topics.patch) - [02-cpptango-telemetry-tracing.patch](/uploads/58855ba78908fe966fe29b4e0d112aa0/02-cpptango-telemetry-tracing.patch) Downsides: - keeping the propagation going while tracing is off (but telemetry on) could have a slight performance impact (not measured). If it is an issue, the user could disable telemetry completely. However, that would also prevent logs going to the telemetry backend. <details> <summary>Click to see some example traces</summary> Example setup: ``` Client -> Leader device -> Follower device ``` The client uses a command on the leader that asks it to "turn on" the follower (via an attribute write). #### Tracing: client (on), leader (on), follower (on) We get a nice single trace covering everything: {width=900 height=477} #### Tracing: client (on), leader (off), follower (on) - current cppTango We get disconnected traces: {width=692 height=118} {width=696 height=113} #### Tracing: client (on), leader (off), follower (on) - proposed fix We still get a single connected trace, but the leader spans are missing, as expected: {width=695 height=226} </details>