Summary
The VPS backend tracing fix switched Sentry initialization to Bun preload (apps/vps/src/instrument.ts) and stopped using the old custom Effect/OpenTelemetry bootstrap path.
We should clean up the leftover pieces once the new tracing flow is confirmed stable in production.
Cleanup items
- Remove
apps/vps/src/lib/otel.ts
- Remove
@sentry/node-core from apps/vps/package.json
- Remove temporary startup diagnostics once tracing is verified:
[sentry] preload init ...[sentry] client already initialized ...
- Revisit whether
otel config in apps/vps/src/services/config.service.ts is still needed
- Revisit whether
OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS should be removed from infra/secrets after rollback risk is gone
Why
These are leftovers from the previous custom OTel setup. Keeping them around makes the tracing setup harder to understand and increases the chance of future confusion when debugging Sentry.
Acceptance criteria
- VPS tracing still works in Sentry after cleanup
- No remaining dead code for the removed custom OTel path
- Config/env surface matches the actual Bun preload-based tracing setup
Summary
The VPS backend tracing fix switched Sentry initialization to Bun preload (
apps/vps/src/instrument.ts) and stopped using the old custom Effect/OpenTelemetry bootstrap path.We should clean up the leftover pieces once the new tracing flow is confirmed stable in production.
Cleanup items
apps/vps/src/lib/otel.ts@sentry/node-corefromapps/vps/package.json[sentry] preload init ...[sentry] client already initialized ...otelconfig inapps/vps/src/services/config.service.tsis still neededOTEL_EXPORTER_OTLP_ENDPOINTandOTEL_EXPORTER_OTLP_HEADERSshould be removed from infra/secrets after rollback risk is goneWhy
These are leftovers from the previous custom OTel setup. Keeping them around makes the tracing setup harder to understand and increases the chance of future confusion when debugging Sentry.
Acceptance criteria