feat(uptime): Enforce per-domain limits

[evanpurkhiser]

Need to fix the test, but this will make it so you can no longer create
more monitors once the per domain limit is reached

[codecov]

❌ 3 Tests Failed:

Tests completed	Failed	Passed	Skipped
21630	3	21627	205

View the top 3 failed tests by shortest run time

tests.sentry.uptime.endpoints.test_project_uptime_alert_index.ProjectUptimeAlertIndexPostEndpointTest test_mode_superadmin

Stack Traces | 3.77s run time

#x1B[1m#x1B[.../uptime/endpoints/test_project_uptime_alert_index.py#x1B[0m:86: in test_mode_superadmin
    resp = self.get_success_response(
#x1B[1m#x1B[.../sentry/testutils/cases.py#x1B[0m:771: in get_success_response
    assert_status_code(response, 200, 300)
#x1B[1m#x1B[.../sentry/testutils/asserts.py#x1B[0m:39: in assert_status_code
    assert minimum <= response.status_code < maximum, (
#x1B[1m#x1B[31mE   AssertionError: (500, b'{"detail":"Internal Error","errorId":null}')#x1B[0m
#x1B[1m#x1B[31mE   assert 500 < 300#x1B[0m
#x1B[1m#x1B[31mE    +  where 500 = <Response status_code=500, "application/json">.status_code#x1B[0m

tests.sentry.uptime.endpoints.test_project_uptime_alert_index.ProjectUptimeAlertIndexPostEndpointTest test

Stack Traces | 3.81s run time

#x1B[1m#x1B[.../uptime/endpoints/test_project_uptime_alert_index.py#x1B[0m:29: in test
    resp = self.get_success_response(
#x1B[1m#x1B[.../sentry/testutils/cases.py#x1B[0m:771: in get_success_response
    assert_status_code(response, 200, 300)
#x1B[1m#x1B[.../sentry/testutils/asserts.py#x1B[0m:39: in assert_status_code
    assert minimum <= response.status_code < maximum, (
#x1B[1m#x1B[31mE   AssertionError: (500, b'{"detail":"Internal Error","errorId":null}')#x1B[0m
#x1B[1m#x1B[31mE   assert 500 < 300#x1B[0m
#x1B[1m#x1B[31mE    +  where 500 = <Response status_code=500, "application/json">.status_code#x1B[0m

tests.sentry.uptime.endpoints.test_project_uptime_alert_index.ProjectUptimeAlertIndexPostEndpointTest test_no_owner

Stack Traces | 3.97s run time

#x1B[1m#x1B[.../uptime/endpoints/test_project_uptime_alert_index.py#x1B[0m:49: in test_no_owner
    resp = self.get_success_response(
#x1B[1m#x1B[.../sentry/testutils/cases.py#x1B[0m:771: in get_success_response
    assert_status_code(response, 200, 300)
#x1B[1m#x1B[.../sentry/testutils/asserts.py#x1B[0m:39: in assert_status_code
    assert minimum <= response.status_code < maximum, (
#x1B[1m#x1B[31mE   AssertionError: (500, b'{"detail":"Internal Error","errorId":null}')#x1B[0m
#x1B[1m#x1B[31mE   assert 500 < 300#x1B[0m
#x1B[1m#x1B[31mE    +  where 500 = <Response status_code=500, "application/json">.status_code#x1B[0m

To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard

[wedamija]

One thought here is that maybe this should happen specifically in the creation function. Since we have the de-duping, it's valid to create a monitor on an existing url even if we're at the limit, since it doesn't cause any more hits to that url.

Maybe the create function could raise an exception that we catch and translate in save?

Maybe also just an edge case and not a big deal

[evanpurkhiser]

oh right, hmm. But you can edit a monitor to change the url as well right. Yeah I guess it could be an exception.

Let's not worry about it for now.