Issue Platform RFC #77
Conversation
This is a draft for the issue platform rfc. Looking for feedback on what else needs to be added - happy to add diagrams, motivations for certain decisions and so on.
|
|
||
| # Summary | ||
|
|
||
| This rfc is intended to provide a high level via of the issue platform, it's |
There was a problem hiding this comment.
| This rfc is intended to provide a high level via of the issue platform, it's | |
| This rfc is intended to provide a high level view of the issue platform, it's |
| - subtitle: str - Used as the sub header on the issue. | ||
| - resource_id: str | None - An optional id that we can use to link to an external system | ||
| - evidence_data: Mapping[str, Any] - An arbitrary json blob of data for use with the frontend to render any custom components necessary for this issue type. | ||
| - evidence_display: A list of data to display in the ui and notifications. This will typically be displayed in a tabular format. Each entry is a dict in format |
There was a problem hiding this comment.
| - evidence_display: A list of data to display in the ui and notifications. This will typically be displayed in a tabular format. Each entry is a dict in format | |
| - evidence_display: A list of data to display in the ui and notifications. This will typically be displayed in a tabular format. Each entry is a dict using the format: |
| - name: str: Name of the value to display in the table | ||
| - value: str: Value to display in the table |
There was a problem hiding this comment.
| - name: str: Name of the value to display in the table | |
| - value: str: Value to display in the table | |
| - name: str - Name of the value to display in the table | |
| - value: str - Value to display in the table |
| - event_id: str - A uuid representing the event id. Pass this if you want to use an event that has already been stored into nodestore. | ||
| - event: dict - A dictionary that matches our event format (https://develop.sentry.dev/sdk/event-payloads/). Pass as much of this as makes sense for your issue type. Use this method if your event isn’t already in nodestore. | ||
|
|
||
| # General Data Flow |
There was a problem hiding this comment.
| # General Data Flow | |
| # General Data Flow | |
|
What's entirely unclear to me right now (even after looking at the code) is the relationship of the issue platform system, with the new occurrences to the existing event and issue APIs. It would be really nice to have a mapping somewhere that explains how we surface out this data, to the existing APIs and whatever new is added. |
| - Improve the release process for new issue types. This is via a policy layer, that will automatically set up ways to release new issue types to LA, EA and GA and save adding a bunch of boilerplate code. | ||
|
|
||
| # Things we’ve cut: | ||
| Errors. We originally had plans to send errors through the issue platform to centralise everything. We’ve decided against this because it seems like a high risk task without much reward. The primary reason we wanted to send errors through the issue platform was so that we could split up detection from ingestion. We might still want to separate detection from ingestion in the future, and this doesn't necessarily have to involve the issue platform, or could involve a separate path through issue platform ingestion that still writes to the same errors dataset. |
There was a problem hiding this comment.
The primary reason we wanted to send errors through the issue platform was so that we could split up detection from ingestion.
Does it matter much for errors? Each event is also an occurrence so there is no real difference between the two.
There was a problem hiding this comment.
The plan now however from my understanding is to move errors onto issue platform. This is something I am at least very interested in as it would allow us to test different versions of grouping algorithms without impacting existing groups.
There was a problem hiding this comment.
Can we keep the storage where it is? that does not impact the grouping algorithm.
The errors cluster is our largest and highly optimized for that kind of load. Moving it to a generic storage would make us loose a lot of efficiency and it would be a very complex operation.
There was a problem hiding this comment.
@fpacifici I'm not involved with the project to move errors to issue platform. There are two things we definitely need to do:
a) we need to enable that an error can exist in two issues. That the existing errors data set does not really support due to it's n:1 relationship
b) from a programming point of view we need to have a reasonable level of abstraction between all the issue types to drive future features such as detecting issue state.
The general assumption that I had is that everything moves over to this new issue world.
|
|
||
| One (but not both) of these should also be passed | ||
| - event_id: str - A uuid representing the event id. Pass this if you want to use an event that has already been stored into nodestore. | ||
| - event: dict - A dictionary that matches our event format (https://develop.sentry.dev/sdk/event-payloads/). Pass as much of this as makes sense for your issue type. Use this method if your event isn’t already in nodestore. |
There was a problem hiding this comment.
Do we actually store this as a dictionary in clickhouse? This would be very inefficient to query.
This is a draft for the issue platform rfc. Looking for feedback on what else needs to be added - happy to add diagrams, motivations for certain decisions and so on.
Describe your RFC briefly so that reviewers can quickly find out what
happens. Also please edit the "Rendered RFC" link so one can quickly
get to the rendered markdown file.
Rendered RFC