How I Tested and Fixed Sensitive Exception Data in OpenTelemetry

I'm building an OpenAI Node.js SDK practice project to explore API integration, testing, documentation, and LLM observability.

One issue I investigated was how my observability wrapper recorded exceptions. The original code called:

span.recordException(error);

In my local tracing demonstration, that resulted in an exported exception event containing a synthetic marker embedded in the error message. It wasn't production data, but it gave me a reproducible example of a privacy risk.

Reproduce before fixing

I added a regression test with a fake marker:

const sensitiveMarker = "PRIVATE_PROMPT_DO_NOT_LOG";
const expectedError = new Error(
  `Provider failure; prompt=${sensitiveMarker}`
);

The test executes the failing operation, flushes the test exporter, and checks the exported span attributes and events. It also confirms that the original error object is still rethrown.

Before the fix, the assertion failed because the marker was present in the exported telemetry.

Change the event, not the failure behaviour

I replaced the raw exception recording with a generic event:

if (error instanceof Error) {
  span.addEvent("exception", {
    "exception.type": "Error",
  });
}

The wrapper still sets the span's status to error and rethrows the original exception. This removes the original message and stack trace from the exception event created by this code path while keeping a generic failure signal.

The trade-off is reduced diagnostic detail. In this practice implementation, the error type is deliberately generic. A more mature system could investigate safe, allowlisted error categories, while ensuring that user input and sensitive data are not embedded in those categories.

Verify the change

The privacy regression test passed after the fix, and the full local test suite passed 57 tests with no failures. The project also runs its automated tests, an OpenTelemetry smoke test, and a documentation-link checker in GitHub Actions.

The tracing example uses mocked SDK responses and a console exporter. It does not prove production telemetry safety or live API behaviour. The fix is not general-purpose redaction: other logging paths and exporters need separate review.

Code and evidence: openai-sdk-docs-practice on GitHub.

For background, OpenTelemetry's exception conventions note that exception messages can contain sensitive information: OpenTelemetry exception conventions.

How do you decide which exception details to keep in telemetry by default?

Comments

[Abhinav Sharma]

Writing the regression test before the fix is the right order - the failing assertion proves the leak is real and the same test guards it afterwards. Allowlisted error categories are a sensible middle ground between full stack traces and a bare error type.