rfc(decision): Replay Issue Creation #92
Conversation
cmanallen
force-pushed
the
rfc/replay-issue-creation
branch
from
784b61c
to
185ca61
Compare
| 2. Provide actionable feedback to developers that could not otherwise be captured in a performance span or error event. | ||
| 3. Increase product awareness in free-tier customers and encourage adoption. | ||
|
|
||
| # Options Considered |
There was a problem hiding this comment.
I'm trying to think of a way to make sure we're looking at an exhaustive list of options, even if some are bad.
here's where i'm starting from:
| SDK | Network data | Relay & Ingest | Result |
|---|---|---|---|
| @sentry/javascript | error payload (call captureException() in browser) |
normal processing | error quota risk |
| @sentry/javascript | click detection (same payload as in experiment) | server-side detector needed | - |
| @sentry/replay | existing breadcrumbs + rrweb events | normal relay processing | server-side detector needed |
| @sentry/replay | click detection breadcrumb (same payload as in experiment) | server-side detector needed | replay must be sampled |
There was a problem hiding this comment.
@ryan953 @cmanallen Could we add a column here that is "Product Experience" or "Product Implications" so we can visualize what this means to our users?
| **Cons:** | ||
|
|
||
| 1. Poor rollout could impact service availability during testing period. | ||
| 2. Requires coordination between the SDK and Ingest to create new issue types. |
There was a problem hiding this comment.
Do we know how perf/profiling teams have been handling their issue types?
IIRC perf issues have been rolled out by a getsentry option, I haven't heard of anything going wrong on their end and I imagine with DS they're also at risk of sampling from the SDK side
There was a problem hiding this comment.
Profiling does it in the back end. Performance I'm not sure exactly. I know they have a lot of back end detectors so at least some portion is handled there.
text/0092-replay-issue-creation.md
Outdated
|
|
||
| **Cons:** | ||
|
|
||
| 1. Uses quota. |
There was a problem hiding this comment.
I assume you mean errors quota here. It would be good to state that specifically for the revised RFC content.
As an aside, is it possible to do Option 1 and exclude it from consuming errors quota?
There was a problem hiding this comment.
^ If the answer is 'yes' to the above question, we'll have to modify the pros/cons list
There was a problem hiding this comment.
There's an experimental REST API (that would not use error quota) but its not stable as of this RFC. We would need to coordinate with the issues team. I don't believe there is another alternative that would not use error quota.
text/0092-replay-issue-creation.md
Outdated
|
|
||
| # Summary | ||
|
|
||
| We want to detect certain categories of issues only available through the Session Replay product. These issues can only be detected on the SDK. The Replay back-end will never have enough data to find these issues. For that reason this is primarily an SDK driven workload. The question is: what role should the Replay back-end have in Replay issue creation? Should the Replay SDK use the Replay back-end to generate new issues or should the SDK generate those issues through a generic, non-replay-specific interface? |
There was a problem hiding this comment.
When we first worked on performance issues the initial spike was doing them via sdk. But there was a lot of pushback to move things to the backend, since implementing this logic across N sdks isn't really a scalable solution.
Maybe this isn't such a big deal if this only applies to the JS world though? Either way it might be worth checking that upper management isn't going to veto this approach later on.
There was a problem hiding this comment.
Maybe this isn't such a big deal if this only applies to the JS world though?
Yeah I'm hoping thats the case.
Unfortunately this work has to be done on the SDK due to the large sizes of replays and the large time differences between segments (segments can refer back to any previous segment). This is probably something that should be documented in the RFC :P
Co-authored-by: Jasmin <[email protected]>
Co-authored-by: Jasmin <[email protected]>
Co-authored-by: Jasmin <[email protected]>
|
The team decided to reopen this RFC in order to expand on the options further. Some of the goals:
|
This RFC proposes two possible paths for creating Replay issues.
Rendered RFC