http.response.status_code always reported as 200

[ilijapuaca]

What version of Elysia is running?

1.4.18

What platform is your computer?

Darwin 25.1.0 arm64 arm

What steps can reproduce the bug?

After upgrading to latest elysia and opentelemetry plugin, all the traces seem to be reported as 200 although that is not the case. The repo should be as simple as the code below and checking the trace out in Jaeger or Datadog

import { Elysia } from 'elysia'
import { opentelemetry } from '@elysiajs/opentelemetry'

import { BatchSpanProcessor } from '@opentelemetry/sdk-trace-node'
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-grpc'
import {ATTR_SERVICE_NAME, ATTR_SERVICE_VERSION} from '@opentelemetry/semantic-conventions';
import {resourceFromAttributes} from '@opentelemetry/resources';

const serviceName = 'elysia-test';
const version = '0.0.0';
const environment = 'dev';

new Elysia()
	.use(
		opentelemetry({
      serviceName: 'elysia-test',
			spanProcessors: [
				new BatchSpanProcessor(
					new OTLPTraceExporter({
            url: 'http://localhost:4317',
            headers: {'Content-Type': 'application/json'},
          })
				)
			],
      resource: resourceFromAttributes({
        [ATTR_SERVICE_NAME]: serviceName,
        [ATTR_SERVICE_VERSION]: version,
        ['deployment.environment']: environment,
      }),
		})
  .get('/test', ({set}) => {
    set.status = 500;
    return 'Hello, world!';
  })
	)
	.listen(3000)

What is the expected behavior?

Correct status code is reported

What do you see instead?

All the traces are tagged as 200 although browser response is confirmed to have non-200 status code

Additional information

No response

Have you try removing the node_modules and bun.lockb and try again yet?

No response

[ilijapuaca]

@SaltyAom this broke our prod as we were left in the dark for a few days before figuring that errors were not being reported correctly

context.set.status seems to be reporting 200 here, I'd like to try and help patch this up but I assume this is an issue with the order in which things are called, or the problem being elsewhere

[ilijapuaca]

response.body also seems to have went away after the last upgrade and it was previously available in traces

[SaltyAom]

should have been fixed by 1.4.9
1.4.8...1.4.9

[ilijapuaca]

@SaltyAom thanks for a quick update. Just wanted to check on this one also, was this intentional, and if so, how would I go about adding this data back into the trace?

response.body also seems to have went away after the last upgrade and it was previously available in traces

[SaltyAom]

updated should be include in 1.4.9

let me deal with npm revoke all access token, and forcing me to use oidc for publishing package until package will be able to publish

[ilijapuaca]

@SaltyAom after upgrading, the status attribute does not seem to be available at all now

Both request and response payload also seems to be gone from the trace

[ilijapuaca]

@SaltyAom any ideas? The package seems broken in its current state without this crucial info being available in traces. I will try and look for a fix this weekend if I get some time, otherwise the only option we have is looking for a version where things worked without issue

[ilijapuaca]

Opened up a PR with fix for the attributes here