This makes a few changes and additions to our types for Seer similar issue requests, in preparation for switching from sending the group id to sending the group hash. Specifically:
Make group_id optional in Seer request and response types, and add an optional group_hash property to both.
Add a SeerSimilarIssueData dataclass, to hold data from Seer about a single similar issue along with the issue's group id. Notes:
Though right now the contents of SeerSimilarIssueData is the same shape as that in SimilarIssuesEmbeddingsData, I chose to create a new type rather than reuse the existing one because once we make the group_id to group_hash switch, they will differ, in that the data which comes back from Seer will have the group's hash and the data we pass around will have the group's id.
I changed the name of SimilarIssuesEmbeddingsData to RawSeerSimilarIssueData to match the new dataclass. I'm not wedded to these names (both SeerSimilarIssueData and RawSeerSimilarIssueData) and open to suggestions here, but I specifically went away from the SimilarIssuesEmbeddingsXXXXX pattern because a) it made them easier to distinguish from the request and reaponse types, and b) I needed a name which indicated that the data is about a single similar issue rather than all of the similar issues and simply changing "Issues" to "Issue" wasn't obvious enough, and c) in SimilarIssuesEmbeddingsXXXXX, the "Issues" is really part of the "similar issues" descriptor on "embeddings", not something naming the contents of the data structure, so I needed "issue" to appear later on in the phrase. I could have gone with SimilarIssuesEmbeddingsIssueData and RawSimilarIssuesEmbeddingsIssueData, but those seemed a little cumbersome. I could be talked into it, though.
This makes a few changes and additions to our types for Seer similar issue requests, in preparation for switching from sending the group id to sending the group hash. Specifically:
Make
group_idoptional in Seer request and response types, and add an optionalgroup_hashproperty to both.Add a
SeerSimilarIssueDatadataclass, to hold data from Seer about a single similar issue along with the issue's group id. Notes:Though right now the contents of
SeerSimilarIssueDatais the same shape as that inSimilarIssuesEmbeddingsData, I chose to create a new type rather than reuse the existing one because once we make thegroup_idtogroup_hashswitch, they will differ, in that the data which comes back from Seer will have the group's hash and the data we pass around will have the group's id.I changed the name of
SimilarIssuesEmbeddingsDatatoRawSeerSimilarIssueDatato match the new dataclass. I'm not wedded to these names (bothSeerSimilarIssueDataandRawSeerSimilarIssueData) and open to suggestions here, but I specifically went away from theSimilarIssuesEmbeddingsXXXXXpattern because a) it made them easier to distinguish from the request and reaponse types, and b) I needed a name which indicated that the data is about a single similar issue rather than all of the similar issues and simply changing "Issues" to "Issue" wasn't obvious enough, and c) inSimilarIssuesEmbeddingsXXXXX, the "Issues" is really part of the "similar issues" descriptor on "embeddings", not something naming the contents of the data structure, so I needed "issue" to appear later on in the phrase. I could have gone withSimilarIssuesEmbeddingsIssueDataandRawSimilarIssuesEmbeddingsIssueData, but those seemed a little cumbersome. I could be talked into it, though.To keep things manageable, I'm going to do the switch to actually using
SeerSimilarIssueDatain a separate PR. [UPDATE: Done in https://github.com/getsentry/sentry/pull/70240.]