From 6280e2dcda1d39b57bf9d25f31ec2a6f63a234b1 Mon Sep 17 00:00:00 2001 From: Charly Gomez Date: Mon, 27 Apr 2026 10:39:43 +0200 Subject: [PATCH] js highlighting --- develop-docs/sdk/telemetry/spans/implementation.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/develop-docs/sdk/telemetry/spans/implementation.mdx b/develop-docs/sdk/telemetry/spans/implementation.mdx index f399bc103ac565..0cbf3ca570487b 100644 --- a/develop-docs/sdk/telemetry/spans/implementation.mdx +++ b/develop-docs/sdk/telemetry/spans/implementation.mdx @@ -124,7 +124,7 @@ The `captureSpan` pipeline emits a `process_span` message that any consumer (e.g The consumer can then apply its logic to spans, similarly to how it might have applied it in event processors before. SDKs having alternative processing patterns established can also use them. -```txt +```js // in captureSpan: processed_span = client.emit("process_span", captured_span) @@ -144,7 +144,7 @@ For event processors mutating data, we need to replace the mutation logic with s SDK-internally, this means configure the integration or call site that registers an event processor, to also register a hook to process that span. As written above, this could be realized via a client lifecycle hook, or a similar mechanism. -```txt +```js // someIntegration: client.addEventProcessor(event => { @@ -169,7 +169,7 @@ This should be the first step we try when implementing span streaming. If this doesn't apply to the use case, we should pre-configure the SDK's `ignore_spans` option and leverage the existing span filtering logic to drop segments or child spans **upfront**. -```txt +```js // someIntegration: client.addEventProcessor(event => {