feat(feedback): use custom prepare/send, re-use createEventEnvelope from core#9432
feat(feedback): use custom prepare/send, re-use createEventEnvelope from core#9432
Conversation
e274114 to
7543baf
Compare
billyvg
left a comment
There was a problem hiding this comment.
If you're reviewing, I'd suggesting viewing the diff between the last 2 diffs as they are 2 diff implementations: client.captureEvent vs a custom capture.
| return client.captureEvent( | ||
| baseEvent, | ||
| { | ||
| event_id: uuid4(), | ||
| }, |
There was a problem hiding this comment.
What are the trade offs for using captureEvent @mydea? We haven't really talked about any hooks that would be needed, but could be a possibility down the road. This would save us from having a lot of custom code, but I don't know how to find out if captureEvent fails so that we can show the user an error.
There was a problem hiding this comment.
I think the core thing is for it to go through event processors etc. Which we have to think about if we want this even 🤔
size-limit report 📦
|
9c4c7cc to
cc43a04
Compare
7543baf to
1a49823
Compare
f88ddde to
380d8fe
Compare
| export type { ServerRuntimeClientOptions } from './server-runtime-client'; | ||
|
|
||
| export * from './tracing'; | ||
| export { createEventEnvelope } from './envelope'; |
There was a problem hiding this comment.
Are we good to export this @mydea?
This also means we'll have to wait for an SDK release before we can release a new version of the SDK
JoshFerge
left a comment
There was a problem hiding this comment.
schema etc. looks good to me. only other thought is i'm wondering if the feedback context should set some kind of signifier that it's the "widget". maybe referrer:widget or feedback_source:widget?
thinking we can do the same for crash report, e.g. feedback_source:crash_report
Remove the use of our temporary ingest endpoint, and use our normal ingestion instead.