-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(core): Add Supabase Queues support #15921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
size-limit report 📦
|
bbadd60
to
e7b3370
Compare
1bc2897
to
d387514
Compare
e7b3370
to
56a2d84
Compare
56a2d84
to
13d60e0
Compare
423397d
to
556703c
Compare
13d60e0
to
74869e4
Compare
e63915a
to
719c8b6
Compare
}, | ||
}, | ||
async span => { | ||
return (Reflect.apply(target, thisArg, argumentsList) as Promise<unknown>).then((res: unknown) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably also end the span when it throws/rejects? We can also set the status of the span then.
name: 'supabase.db.rpc', | ||
attributes: { | ||
[SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN]: 'auto.db.supabase', | ||
[SEMANTIC_ATTRIBUTE_SENTRY_OP]: op, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can add the messaging.system
attribute to be 'supabase'
as described in https://develop.sentry.dev/sdk/telemetry/traces/modules/queues/
const isProducerSpan = argumentsList[0] === 'enqueue'; | ||
const isConsumerSpan = argumentsList[0] === 'dequeue'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if this recently changed, but here they show send
and pop
as rpc args: https://supabase.com/docs/guides/queues/quickstart#enqueueing-and-dequeueing-messages 🤔
fb8eeb1
to
a8da234
Compare
ff2f804
to
5ce5ee9
Compare
@sentry review |
On it! We are reviewing the PR and will provide feedback shortly. |
PR DescriptionThis pull request introduces instrumentation for Supabase queue operations using pgmq, enabling Sentry to capture spans and breadcrumbs for queue publishing and processing. This provides visibility into asynchronous task execution within Supabase applications. Click to see moreKey Technical ChangesThe key technical changes include: 1) Instrumenting the Architecture DecisionsThe primary architectural decision involves using Proxy objects to intercept calls to the Supabase client's Dependencies and InteractionsThis integration depends on the Risk ConsiderationsPotential risks include: 1) Performance overhead due to the instrumentation, although proxies are generally performant. 2) Incorrectly identifying queue operations, leading to spurious spans. 3) Failure to propagate trace context if consumers are not properly instrumented. 4) Security implications of modifying message bodies, although the injected data is limited to Sentry trace context. 5) The modification of the arguments list in place could lead to unexpected side effects. Notable Implementation DetailsNotable implementation details include: 1) The use of |
4f19854
to
1c518a2
Compare
anybody got eyes on this anymore? 😅 |
1c518a2
to
327b57a
Compare
327b57a
to
1ed3684
Compare
}); | ||
}, | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Supabase RPC Error Handling Flaws
The instrumentRpcConsumer
and instrumentRpcProducer
functions throw a TypeError
when computing messageId
. This occurs because res?.data?.map(...).join(',')
attempts to call join
on undefined
if res.data
is null
or undefined
, which is common for Supabase RPC error responses. This prevents proper error handling (span status, exception capture), masks the original error, and can crash the application. A defensive check (e.g., Array.isArray(res.data)
) is required. Additionally, the captureException
call in instrumentRpcConsumer
for Supabase errors is missing the mechanism
attribute, which should be { handled: false, type: 'auto.db.supabase' }
.
}, | ||
}, | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Supabase Integration Errors: Exception Handling, Proxying, and Redundancy
The Supabase integration has three issues:
captureException
in theinstrumentRpcProducer
's error handling lacks amechanism.type
, violating SDK conventions for proper error classification.instrumentRpc
unconditionally proxiesclient.rpc
. If the Supabase constructor (instead of an instance) is passed toinstrumentSupabaseClient
,client.rpc
isundefined
, causingnew Proxy(undefined, ...)
to crash Sentry initialization.- The
rpc
method (andschema
'srpc
method) is proxied without an idempotency guard. This allows multiple wraps if the integration is initialized more than once, leading to duplicate spans, breadcrumbs, and_sentry
metadata injection.
}); | ||
}, | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Missing Mechanism Attributes in Exception Capture
captureException
calls in instrumentRpcConsumer
and instrumentRpcProducer
are missing required mechanism
attributes. Specifically, mechanism.handled
and mechanism.type
are missing in instrumentRpcConsumer
and the res.error
path of instrumentRpcProducer
. The catch
path in instrumentRpcProducer
sets mechanism.handled
but omits mechanism.type
. Per SDK guidelines, all captureException
calls must include both mechanism.handled
and a mechanism.type
(e.g., auto.db.supabase.queue
) for consistent error context and diagnostics.
Additional Locations (1)
// and should not be instrumented here. | ||
return Reflect.apply(target, thisArg, argumentsList); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: RPC Observability Regression
Supabase RPC calls are no longer instrumented. The PostgRESTFilterBuilder
now skips /rpc
paths, and the new RPC instrumentation only covers queue operations (send
, send_batch
, pop
). This regression causes a loss of spans and breadcrumbs for all other RPC calls, impacting observability.
Resolves: #14611
Summary:
Sample Queue Event: Link
supabaseClient.rpc('<queue_op>', ...)
supabaseClient.schema(...).rpc('queue_op', ...)
producer
ops:send
,send_batch
consumer
op:pop