feat(ACI): Add API documentation for OrganizationDetectorIndexEndpoint POST#105882
feat(ACI): Add API documentation for OrganizationDetectorIndexEndpoint POST#105882
Conversation
src/sentry/workflow_engine/endpoints/organization_detector_index.py
Outdated
Show resolved
Hide resolved
06c3d40 to
06d1d5f
Compare
src/sentry/workflow_engine/endpoints/validators/base/detector.py
Outdated
Show resolved
Hide resolved
|
|
||
| @property | ||
| def data_sources(self) -> serializers.ListField: | ||
| # TODO - improve typing here to enforce that the child is the correct type |
There was a problem hiding this comment.
The API docs do not currently support a single endpoint having multiple serializers as we have for detectors. In order to unblock deprecation I am sort of hacking this - every detector type except for the error detector has data_sources, and in order to get that to show up in the documentation I had to add it to the base detector and remove the not implemented definition here. I know this is not ideal, but it's the best we can do right now.
| parameters=[ | ||
| GlobalParams.ORG_ID_OR_SLUG, | ||
| ], | ||
| request=PolymorphicProxySerializer( |
There was a problem hiding this comment.
This unfortunately doesn't work for the API docs even though it's a part of DRF spectacular. It generates a "one of many" that the API docs fail when trying to parse.
|
|
||
| @extend_schema( | ||
| operation_id="Create a Detector", | ||
| operation_id="Create a Monitor for a Project", |
There was a problem hiding this comment.
I can't make this titled "Create a Monitor" because there's already a published cron endpoint with that title. Since you need to supply a project ID here anyway I think it's ok.
mifu67
left a comment
There was a problem hiding this comment.
Looks good to me; @saponifi3d let me know if you want to take a look, otherwise I'll approve.
| description = serializers.CharField(required=False, allow_null=True, allow_blank=True) | ||
| enabled = serializers.BooleanField(required=False) | ||
| condition_group = BaseDataConditionGroupValidator(required=False) | ||
| type = serializers.CharField(help_text="The type of monitor - 'metric_issue'") |
There was a problem hiding this comment.
Should we list potential monitor types here?
There was a problem hiding this comment.
I removed the other types (crons and uptime) for the time being since we're not documenting how to make those at this time. I'm going to have the crons team add to this with their payloads.
| required=False, | ||
| allow_null=True, | ||
| allow_blank=True, | ||
| help_text="A description of the monitor. Will be displayed in the resulting notification.", |
There was a problem hiding this comment.
Monitors don't send notifications by default, but up to you on changing this.
There was a problem hiding this comment.
Do you think I should completely leave out the last sentence? It can be a nice surprise that it shows up if there is a notification 😓
There was a problem hiding this comment.
🤔 maybe it will be used in the resulting issue? That's really where it's coming from on the notification, and where the description goes for the monitor.
| CREATE_DETECTOR = [ | ||
| OpenApiExample( | ||
| "Monitor successfully created", | ||
| value={ |
There was a problem hiding this comment.
🤔 not for today / this pr, but i wonder if we could generate these responses from the API so it automatically stays up to date.
src/sentry/workflow_engine/endpoints/validators/base/detector.py
Outdated
Show resolved
Hide resolved
| required=False, | ||
| allow_null=True, | ||
| allow_blank=True, | ||
| help_text="A description of the monitor. Will be displayed in the resulting notification.", |
There was a problem hiding this comment.
🤔 maybe it will be used in the resulting issue? That's really where it's coming from on the notification, and where the description goes for the monitor.
| enabled = serializers.BooleanField( | ||
| required=False, help_text="Set to False if you want to disable the monitor." | ||
| ) | ||
| condition_group = BaseDataConditionGroupValidator( |
There was a problem hiding this comment.
i wonder if this is something we should define generically or not. something like talking about the logic type then it being conditions, then having a list of different condition values / models etc that we can associate here. Is it possible to nest model documentation like that with drfspectaular?
There was a problem hiding this comment.
I don't think we can do nesting, but as an example I think https://docs.sentry.io/api/alerts/create-a-metric-alert-rule-for-an-organization/ is one of the more complicated documented endpoints we have and this uses a very long docstring. I like that this one lists out eventTypes values for example.
| **Threshold & Change** | ||
| ```json | ||
| "id": "1234567", | ||
| "organizationId": "1", |
There was a problem hiding this comment.
Just thinking about the API itself, should / do we need to return the org id on the condition group? wonder if we can remove it and save a few bytes.
There was a problem hiding this comment.
I'm not sure what it's used for in the response but this did make me realize it's not needed in the post body so I removed it 👍
7701a6f to
9eba66a
Compare
|
@saponifi3d ok check it out again, I re-organized things so it's roughly in order of what you'd set up in the UI and I added descriptions and available options. The screenshot looks wonky but I swear if you click to open it in a new page and click once more it's normal looking. |
src/sentry/workflow_engine/endpoints/validators/base/detector.py
Outdated
Show resolved
Hide resolved
9eba66a to
807f979
Compare
807f979 to
978aeae
Compare
malwilley
left a comment
There was a problem hiding this comment.
Incredibly thorough! Looks good to me, I couldn't find any errors.
1b64afb to
d7ea5f2
Compare
Follow up to #106025 to add documentation for the POST
OrganizationDetectorIndexEndpoint.This will not be published yet, but in order to deploy this in pieces we'll set the
publish_statustoPUBLICall at once and add the sidebar item for workflow engine.The POST endpoint handles multiple detector types with various additional body params which isn't supported in our API documentation (it expects a single serializer), so I've done something similar to how we document the issue alert creation endpoint. This will need updating if we add more detector types, but unless the documentation framework is changed to support multiple serializers this is the best we can do.