-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Amend RFC 92 With New Options #99
Conversation
- Requires SDK changes. | ||
- Requies code changes by the Issues team to create a generic interface for creating issues. | ||
- This would likely disrupt our June 18 deadline. | ||
- Unless the Issues team has excess capacity and a willingness to work on it immediately. |
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.
it also seems like we'd also want to do this in Relay -- we try not to have python endpoints be hit by SDKs. seems like it would be a large amount of work.
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.
Seems like this would be the Issues teams problem... sorry @wedamija 😆. But seriously, I could contribute to this if the Issues team needs help. Dan do you have any feedback on option 2? (or any option really)
Co-authored-by: Bruno Garcia <[email protected]>
Co-authored-by: Bruno Garcia <[email protected]>
Co-authored-by: Bruno Garcia <[email protected]>
Co-authored-by: Bruno Garcia <[email protected]>
Out of the options here this really should be option 3. I don’t like the idea if creating issues directly from the SDK. On the one hand for abuse reasons, on the other for flexibility reasons if we want to change how these issues behave. |
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.
suggested decision
- Significantly smaller pool of customers who will see "slow click" issues. | ||
- Requires code changes by the Session Replay back-end team. | ||
- Requires addition of event sampling, issue platform integration, and merging of the replay-event and recording-event payloads. | ||
- Merging the replay-event and recording-event payloads together is not a trivial change and requires careful deployment. | ||
|
||
# Unresolved questions |
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.
For Option 1: SDK Creates Issues With "captureException" Method, we should think about:
- How valuable and/or actionable are dead click issues without replays?
- If we can provide dead click issues without Replay being installed, will customers be incentivized to install Replay?
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 put both of these bullets as Cons inside (especially) option 1
Co-authored-by: Bruno Garcia <[email protected]>
Co-authored-by: Jasmin <[email protected]>
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.
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.
Since they inverted the buttons, it really gets me
Rendered RFC