feat(core): Add Supabase Queues support#15921
Conversation
size-limit report 📦
|
onurtemizkan
force-pushed
the
onur/supabase-queues
branch
from
bbadd60 to
e7b3370
Compare
onurtemizkan
force-pushed
the
onur/supabase-integration
branch
from
1bc2897 to
d387514
Compare
onurtemizkan
force-pushed
the
onur/supabase-queues
branch
from
e7b3370 to
56a2d84
Compare
onurtemizkan
force-pushed
the
onur/supabase-queues
branch
from
56a2d84 to
13d60e0
Compare
onurtemizkan
force-pushed
the
onur/supabase-integration
branch
4 times, most recently
from
423397d to
556703c
Compare
onurtemizkan
force-pushed
the
onur/supabase-queues
branch
from
13d60e0 to
74869e4
Compare
onurtemizkan
force-pushed
the
onur/supabase-queues
branch
from
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.
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.
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.
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 🤔
onurtemizkan
force-pushed
the
onur/supabase-queues
branch
4 times, most recently
from
fb8eeb1 to
a8da234
Compare
onurtemizkan
force-pushed
the
onur/supabase-queues
branch
2 times, most recently
from
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 |
![seer-by-sentry[bot]](https://avatars.githubusercontent.com/in/801464?s=60&v=4){kind=small}
onurtemizkan
force-pushed
the
onur/supabase-queues
branch
from
608b31d to
71c40cf
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| // even if the prototype's .then is already instrumented | ||
| if (_isInstrumented(originalThen) && !hasOwnThen) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
Incorrect guard allows double-wrapping of instrumented instances
Low Severity
The guard condition in _instrumentPostgRESTFilterBuilderInstance has flawed logic. The condition _isInstrumented(originalThen) && !hasOwnThen only returns early when the prototype's .then is instrumented AND there's no own property. However, if an instance has its own .then that is already instrumented (e.g., from a previous call), the condition evaluates to true && false = false, allowing the function to proceed and double-wrap the already-instrumented Proxy. The condition should simply be _isInstrumented(originalThen) to prevent wrapping any already-instrumented .then, regardless of whether it's an own property or inherited.
Codecov Results 📊Generated by Codecov Action |
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.
| if (rpcFunctionName && QUEUE_RPC_OPERATIONS.has(_normalizeRpcFunctionName(rpcFunctionName))) { | ||
| // Queue RPC calls are instrumented in the dedicated queue instrumentation. | ||
| return Reflect.apply(target, thisArg, argumentsList); | ||
| } |
There was a problem hiding this comment.
Non-queue RPC calls get double instrumentation
Low Severity
Non-queue RPC calls receive duplicate span instrumentation. The new _instrumentGenericRpc creates a span with description rpc(functionName), but when the result's .then() is called, the PostgREST instrumentation also runs because it only skips queue operations (QUEUE_RPC_OPERATIONS). This creates a second span describing the same call as insert(...) from(functionName). The skip condition at line 73 checks only for queue RPC names but allows all other RPC calls to be instrumented again by the PostgREST path.
Additional Locations (1)
4 participants
Resolves: #14611
This PR adds Supabase Queues support to the Supabase
Sample Events: Link
Instrumented Operations
Producer operations (
queue.publish):send- Send a single messagesend_batch- Send multiple messagesConsumer operations (
queue.process):pop- Read and delete messageread- Read message (with visibility timeout)receive- Alias forreadSpan Attributes
Follows OTEL Messaging Semantic Conventions and Sentry Queue Developer Docs:
messaging.destination.name- Queue namemessaging.message.id- Message ID (frommsg_id)messaging.message.retry.count- Retry count (from PGMQ'sread_ct)messaging.batch.message_count- Batch size forsend_batchDistributed Tracing
Producer spans inject
sentry-traceandbaggageinto the message payload under_sentrykey. Consumer spans create span links to the producer trace context.Notes
client.rpc()andclient.schema('pgmq_public').rpc()patternssend,send_batch,pop,read,receivemessaging.batch.message_count: 0