Sentry in background actions
I've got some errors that have been thrown in background actions, which I am catching with Sentry — do background actions have awareness of what DSN they are sending to? We only seem to have captured exceptions that have occurred in CRUD actions
11 Replies
Hello,
Sorry for the late reply, the team had a very busy week last week and I was not able to get to everyone's questions.
I'm going to look into this. Its seems like this might be a bug on our end and that we're not setting a field(s) that should be part of the payload.
Background actions should be setup with the Sentry DSN just like regular actions. Do you have an example of a particular error that wasn't sent to Sentry that should have been?
Yep I do:
TraceID:
72e1039dd57473a1bbf810384124165f
Received a GGT_DATABASE_OPERATION_TIMEOUT error inside a background action, and there is no record of that in Sentry
Perfect, I'll investigate this today 👍
Thanks Scott
I figured out the issue.
First I tried to reproduce this by creating a
ping action that always throws an error. I then setup the Sentry plugin and enqueued the action. The errors from the enqueued action (including all its retries) ended up being sent to Sentry, so we do send errors to Sentry like I thought.
However, I looked into the trace you provided and it's a little more complicated...
In the trace you provided, that background action was from a
orders/updated shopify webhook, which ends up calling a model action. When we process model actions, we first fetch the existing database record to populate the record object in your action's context. We fetch the database record on Gadget's servers before sending the record to your application's server. Your application's server is configured with Sentry when it boots up, so any errors that occur there will automatically be sent to your Sentry DSN. However, Gadget's servers are setup with our own internal Sentry DSN, so if an error occurs on our server -- like timing out while loading the database record to send to your server -- then the error isn't sent to your Sentry DSN, it's sent to ours...
That's exactly what happened in the trace you provided 😐@LittleTojo Okay I understand- is there a way around this or would it be something of a complex undertaking for Gadget to support this?
Unfortunately, this would be quite the complex undertaking for Gadget to support this 😔
That hasn't stopped us before though, so I created a ticket and brought it up to the team.