[RDKE] [RBUS] Enable Cross-Path Trace Context Propagation

[tabbas651]

Reason for change: When provider component acquires TraceParent & TraceContext using OTEL and Sets to RBUS>
The provider component, calls RPC operations like EventPublish The consumer/subscriber callback receives the same TraceParent & TraceContext
Test Procedure: Refer the ticket descriptions
Risks: Medium
Priority: P0

[github-actions]

Code Coverage Summary

                                        Total:|62.4%  2813|64.8% 247|    -    0

[Copilot]

🟡 Changes recommended

The new OTLP instrumentation introduces unit-test build/link breakage risk and trace-context propagation is not made atomic against concurrent RBUS usage of the shared global handle.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Enables OpenTelemetry distributed trace context propagation across RBUS by initializing OTLP instrumentation in the RBUS DML provider and attaching/clearing RBUS trace context around an event publish in the DeviceInfo remote-debugger setter.

Changes:

• Link DeviceInfo profile with rdk_otlp (-lrdk_otlp).
• Initialize OTLP instrumentation during RBUS DML provider startup.
• Start/finish a distributed trace and set/clear RBUS trace context around rbusEvent_Publish() for the remote-debugger issue event.

File summaries

File	Description
src/hostif/profiles/DeviceInfo/Makefile.am	Adds -lrdk_otlp to support new OTLP instrumentation calls from DeviceInfo code.
src/hostif/profiles/DeviceInfo/Device_DeviceInfo.cpp	Starts an OTLP distributed trace and propagates trace context into RBUS before publishing the remote-debugger issue event.
src/hostif/handlers/src/hostIf_rbus_Dml_Provider.cpp	Initializes OTLP instrumentation during RBUS DML provider initialization.

Review details

Suppressed comments (1)

src/hostif/profiles/DeviceInfo/Device_DeviceInfo.cpp:4029

• rbusHandle_SetTraceContextFromString()/rbusHandle_ClearTraceContext() mutate trace context on the shared global rbusHandle. Since tr69hostif is multi-threaded, other threads can interleave RBUS calls while the context is temporarily set here, causing trace context to “bleed” into unrelated RBUS operations (or vice-versa).

To make propagation reliable, ensure the set→publish→clear sequence is atomic across all RBUS users (e.g., a global RBUS mutex used by all RBUS operations that can run concurrently, or a dedicated per-operation RBUS handle for publishing).

    if(issueStr == NULL)
    {
        RDK_LOG(RDK_LOG_ERROR,LOG_TR69HOSTIF,"[%s %d] Memory Allocation Failed.\n",__FUNCTION__,__LINE__);
	return retVal;
    }

• Files reviewed: 3/3 changed files
• Comments generated: 3
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

The new OTLP symbols are used by multiple binaries/objects, but link flags are only updated in one profile Makefile, which is likely to break linking for tr69hostif and/or existing gtest targets.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

[github-actions]

Code Coverage Summary

                                        Total:|62.5%  2813|65.2% 247|    -    0

[Copilot]

🟡 Changes recommended

Unresolved OTLP linkage, incomplete trace-context propagation, and insufficient test coverage remain.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (4)

src/hostif/handlers/src/hostIf_rbus_Dml_Provider.cpp:468

• This reference is introduced in libMsgHandlers.la, but src/hostif/handlers/Makefile.am still does not link -lrdk_otlp; the flag added under DeviceInfo only makes the final daemon link succeed accidentally when that profile is also present. Targets that link the handler library independently, including handlers_gtest, get an undefined reference to rdk_otlp_init. Declare the dependency for the handler target and its tests (preferably through configure/pkg-config).

    rdk_otlp_init("tr69hostif_provider", "1.0.0");

src/hostif/profiles/DeviceInfo/Device_DeviceInfo.cpp:4238

• The existing unit-test RBUS stubs declare rbusHandle_SetTraceContextFromString and rbusHandle_ClearTraceContext but do not define them. Because the gtest targets compile Device_DeviceInfo.cpp directly, these new calls will produce unresolved symbols; add stub implementations (and assertions if propagation is tested) or link the real RBUS library for those targets.

        rbusError_t clearTraceRc = rbusHandle_ClearTraceContext(rbusHandle);

src/hostif/profiles/DeviceInfo/Device_DeviceInfo.cpp:4198

• This wraps only RRD_SET_ISSUE_EVENT. The same provider has other rbusEvent_Publish paths for RRD_WEBCFG_ISSUE_EVENT, RDK_REBOOTSTOP_ENABLE, and RDM_DOWNLOAD_EVENT, which still publish without setting the RBUS trace context, so cross-path propagation remains absent for those subscriber callbacks. Apply the same sequence through a shared publish helper or instrument each intended path.

    rdk_otlp_start_distributed_trace(RRD_SET_ISSUE_EVENT, "publish");

src/hostif/profiles/DeviceInfo/Makefile.am:35

• The new rdk_otlp_* calls are built into libMsgHandlers as well as libdeviceinfo, but this adds -lrdk_otlp only to DeviceInfo's link flags. The DeviceInfo and handlers gtest targets compile these sources directly and their COMMON_LDADD values do not link librdk_otlp; dm_stubs.cpp also has no definitions for the newly used RBUS trace APIs. Those test binaries will therefore fail at link time, and the handler library does not declare its own dependency. Move the library dependency to the target/library that uses it and add the required test stubs or test link dependencies.

AM_LDFLAGS = $(PROCPS_LIBS) -lIARMBus -lyajl -ldbus-1 -lcurl -lrfcapi -lrbus -luploadstblogs -lrdk_otlp

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Lite