Allow explicit context for OpenTelemetry logs

[florian-rhinow]

Summary

• allow OpenTelemetryLogsOutputPlugin callers to provide either a fixed OpenTelemetry Context or a per-record context resolver
• preserve the existing behavior when no context is configured, so the Logs SDK continues to capture context.active()
• add library-local SDK tests for active non-recording context, explicit context, resolver override, severity, body, and attributes

Root cause

OpenTelemetryLogsOutputPlugin.writeRecord() currently calls Logger.emit() without a context. The OpenTelemetry Logs SDK therefore snapshots context.active() at emit time. In framework integrations, that active context can contain a non-recording span whose span ID is never exported, even when the consumer already has the recording HTTP SERVER span context available. The resulting log record is correlated to a span that cannot be found in the trace backend.

This change keeps the plugin framework-agnostic: consumers can supply the correct context directly or resolve it lazily for each log record. There is no xotel-specific behavior.

Validation

Rebased onto the refreshed opentelemetry-v8 branch (f884349).

• npm ci
• npm run build
• npx mocha src/test/unit-test/otel-output.test.js — 3 passing
• npm run lint
• npm test — 177 passing
• git diff --check

[cla-assistant]

All committers have signed the CLA.

[florian-rhinow]

@christiand93 This is a small follow-up to the OTel plugin on #316: it lets consumers provide the explicit OTel Context that Logger.emit() already supports, with backward-compatible defaults and focused SDK tests. Review would be appreciated. The contributor CLA check is currently pending.

[florian-rhinow]

@christiand93 Rebased onto the refreshed opentelemetry-v8 (f884349) and force-pushed. The rebase was clean: Git dropped the now-upstream plugin commit and replayed only the context-resolver change. Validation is fully green now: build, lint, focused OTel tests (3/3), and complete suite (177/177).

[christiand93]

Cool, thank you for contributing.
Looks good to me 🦘

Make sure to sign the CLA:
#350 (comment)

[florian-rhinow]

@christiand93 I investigated the pending CLA check against SAP OSPO guidance and CLA Assistant itself. florian-rhinow is an active public member of the GitHub SAP organization (GET /orgs/SAP/public_members/florian-rhinow returns 204), and the commit is attributed to florian.rhinow@sap.com. The check was retriggered after the rebase/force-push and remains pending, so this is not stale caching. CLA Assistant only exempts public organization members when the linked repository configuration has that organization in allowListPatternOrgs (the “organization public member exempt list”). Could you please verify that SAP is configured in that field for SAP/cf-nodejs-logging-support and trigger Re-check pull requests in CLA Assistant? Current SAP OSPO guidance says public SAP org membership should skip the employee CLA/DCO check.

[christiand93]

Afaik, cla-assistant is managed centrally/by OSPO and I don't seem to have access to its configuration. I will reach out to OSPO to get some help.