feat(deno): redis diagnostics channel based integration for deno#21087
feat(deno): redis diagnostics channel based integration for deno#21087isaacs wants to merge 1 commit into
Conversation
size-limit report 📦
|
) Refactor the redis-dc integration logic into core/src/integrations, and create a Deno integration that uses the same patterns. Instead of the @sentry/opentelemetry/tracing-channel, the Deno integration just adds `_sentrySpan` onto the data in a RedisTracingChannelFactory which is passed to the core utility. Add deno-redis e2e test.
f176fd8 to
0fc320c
Compare
1048f32 to
72be1fa
Compare
) Refactor the redis-dc integration logic into core/src/integrations, and create a Deno integration that uses the same patterns. Instead of the @sentry/opentelemetry/tracing-channel, the Deno integration just adds `_sentrySpan` onto the data in a RedisTracingChannelFactory which is passed to the core utility. Add deno-redis e2e test.
11525d8 to
a8d3cb7
Compare
8226aaf to
5863e6c
Compare
) Refactor the redis-dc integration logic into core/src/integrations, and create a Deno integration that uses the same patterns. Instead of the @sentry/opentelemetry/tracing-channel, the Deno integration just adds `_sentrySpan` onto the data in a RedisTracingChannelFactory which is passed to the core utility. Add deno-redis e2e test.
5863e6c to
cd298fa
Compare
|
👋 @mydea, @andreiborza — Please review this PR when you get a chance! |
) Refactor the redis-dc integration logic into core/src/integrations, and create a Deno integration that uses the same patterns. Instead of the @sentry/opentelemetry/tracing-channel, the Deno integration just adds `_sentrySpan` onto the data in a RedisTracingChannelFactory which is passed to the core utility. Add deno-redis e2e test.
cd298fa to
b4e4854
Compare
) Refactor the redis-dc integration logic into core/src/integrations, and create a Deno integration that uses the same patterns. Instead of the @sentry/opentelemetry/tracing-channel, the Deno integration just adds `_sentrySpan` onto the data in a RedisTracingChannelFactory which is passed to the core utility. Add deno-redis e2e test.
b4e4854 to
9217baa
Compare
) Refactor the redis-dc integration logic into core/src/integrations, and create a Deno integration that uses the same patterns. Instead of the @sentry/opentelemetry/tracing-channel, the Deno integration just adds `_sentrySpan` onto the data in a RedisTracingChannelFactory which is passed to the core utility. Add deno-redis e2e test.
e46685b to
1f6c601
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 1f6c601. Configure here.
| }, | ||
| ]; | ||
|
|
||
| const utf8Decoder = new TextDecoder('utf-8'); |
There was a problem hiding this comment.
Top-level side effect contradicts sideEffects: false
Medium Severity
const utf8Decoder = new TextDecoder('utf-8') is a top-level constructor call (side effect) in a module reachable from @sentry/core's public entry points (server-exports.ts → index.ts). The @sentry/core package declares "sideEffects": false, so bundlers assume every module is purely declarative and may skip executing top-level code. Every other new TextDecoder() / new TextEncoder() call in @sentry/core is scoped inside a function; this is the only module-scope instance. The decoder should be instantiated inside defaultDbStatementSerializer instead.
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 1f6c601. Configure here.
JPeer264
left a comment
There was a problem hiding this comment.
LGTM, just have one m which I want to get sorted before approving
| setupCommandChannel(tracingChannel); | ||
| setupBatchChannel(tracingChannel); | ||
| setupConnectChannel(tracingChannel); | ||
| subscribed = true; |
There was a problem hiding this comment.
l: Could it be that the second or third command fails that keeps subscribed = false? It will be called anyways just once, but I think there could be a potential double instrumentation, no?
| setupConnectChannel(tracingChannel); | ||
| subscribed = true; | ||
| } catch { | ||
| // The factory may rely on `node:diagnostics_channel`, which isn't always |
There was a problem hiding this comment.
l: Should we emit a debug log here?
| [SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN]: ORIGIN, | ||
| [SEMANTIC_ATTRIBUTE_SENTRY_OP]: 'db.redis', | ||
| [ATTR_DB_SYSTEM]: DB_SYSTEM_VALUE_REDIS, | ||
| ...(data.batchSize != null ? { 'db.redis.batch_size': data.batchSize } : {}), |
There was a problem hiding this comment.
m: Before we add db.redis.batch_size we should add it to our semantic conventions. I've also seen that for databases the convention is batch.size, so I wonder if we should rather go for this instead: https://opentelemetry.io/docs/specs/semconv/registry/attributes/db/
| export { instrumentPostgresJsSql } from './integrations/postgresjs'; | ||
|
|
||
| export { | ||
| REDIS_DC_CHANNEL_BATCH, |
There was a problem hiding this comment.
l: One more thing I've noticed while reviewing quickly #21187
Since more and more names will be exported over time we could align on a common wording somewhere for these channel constants.
|
👋 @mydea, @andreiborza — Please review this PR when you get a chance! |
I'm personally fine with this. Approved the other PR, waiting for @isaacs decision. |


Refactor the redis-dc integration logic into core/src/integrations, and create a Deno integration that uses the same patterns.
Instead of the @sentry/opentelemetry/tracing-channel, the Deno integration just adds
_sentrySpanonto the data in a RedisTracingChannelFactory which is passed to the core utility.