Open dcramer opened 11 months ago
The interesting part is, we may get this without using a Sentry SDK on the server.
With #515 and #530 I think we have everything in place from Spotlight side. We were able to demonstrate the usage of these with getsentry/sentry-python#3600 and getsentry/sentry-python#3614 so I'll keep this open to track SDK integrations but I don't think we need anything more on Spotlight side.
We need to adjust the way the SDK and Spotlight inteteract to support a better workflow.
Ideal outcome:
I dont know exactly what this looks like in practice, but in SDKs we already return eventID from things like
captureException()
. We almost need that kind of behavior, but with the abilty to also grab the event payload.Implementation wise we should look at Django, Laravel, and Rails. All have error frameworks to make this drop-in. In Laravel, for example, we need to hook it here:
The error handler gets passed the exception, which at this point - similar to how User Feedback integration works - we'd need to get the payload. It's possible "the last error generated" is fine (I'm not sure), but "the last event" is probably incorrect these days. Really we want "the last unhandled error" OR we want a clean way to just pull the guaranteed payload of an exception.
On this error page, or on a generic injection thats available everywhere, it then becomes as easy as
Spotlight.init()
andSpotlight.trigger("sentry:showError", {eventId: event.event_id, event})
.For more clarity on the DX and how it must work, image you have
500.blade.php
: