Skip to content

Conversation

julienbourdeau
Copy link
Contributor

@julienbourdeau julienbourdeau commented Apr 28, 2025

  • Introduce UsageMonitoring::Alert model with STI. Each type of alert get it's own child class
    • The specific alert class is meant to be able to find it's "current value" in a given object
    • We do this to compute current_usage only once and pass it to all alerts
  • Process Alerts when process SubscriptionActivity, together with progressive billing
    • Ensure having one alert breaking keep the other running
    • Ensure having progressive billing keep the alert running
  • Create, Update, Destroy services
  • GraphQL layer

@julienbourdeau julienbourdeau self-assigned this Apr 28, 2025
@julienbourdeau julienbourdeau changed the title Introduce Alerting 🔔 feat(alerting): Introduce Alerting 🔔 Apr 28, 2025
@julienbourdeau julienbourdeau force-pushed the feat/subscription-activity branch from 018badd to 1e96836 Compare April 28, 2025 20:04
Base automatically changed from feat/subscription-activity to main April 29, 2025 07:07
@julienbourdeau julienbourdeau force-pushed the feat/alerting branch 4 times, most recently from 203040b to b2c4526 Compare May 5, 2025 12:11
@julienbourdeau julienbourdeau marked this pull request as ready for review May 5, 2025 14:59
@julienbourdeau julienbourdeau force-pushed the feat/alerting branch 10 times, most recently from 9e5c5b8 to 66af702 Compare May 7, 2025 07:00
@julienbourdeau julienbourdeau force-pushed the feat/alerting branch 3 times, most recently from 89a8981 to 804c566 Compare May 19, 2025 09:15
@julienbourdeau julienbourdeau force-pushed the feat/alerting branch 2 times, most recently from 5a1a8cf to 59688ce Compare May 19, 2025 10:14
@julienbourdeau julienbourdeau force-pushed the feat/alerting branch 3 times, most recently from 96fb30a to d590cda Compare May 19, 2025 11:17
Copy link
Collaborator

@vincent-pochet vincent-pochet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍

@julienbourdeau julienbourdeau merged commit 865c85f into main May 20, 2025
14 checks passed
@julienbourdeau julienbourdeau deleted the feat/alerting branch May 20, 2025 08:53
julienbourdeau added a commit that referenced this pull request May 22, 2025
…alerts (#3690)

## Context

We're adding Alerting feature, see #3528, #3535, #3554, #3600

## Description

We introducing 2 new types of alerts:
* LifetimeUsageAmount: to define alert based on lifetime total usage
* BillableMetricUsageUnits: same as BillableMetricUsageAmount but with a
number "used units" instead of currency amount.

Creating a new alert is essentially creating a new child class of
`UsageMonitoring::Alert` and implementing `find_value`. 🙌
julienbourdeau added a commit that referenced this pull request Jun 2, 2025
Alerts were recently introduced in #3554 

This PR adds Rest API endpoints to manage the alerts.

```
GET    /api/v1/subscriptions/:external_id/alerts
POST   /api/v1/subscriptions/:external_id/alerts
GET    /api/v1/subscriptions/:external_id/alerts/:code
PUT    /api/v1/subscriptions/:external_id/alerts/:code
DELETE /api/v1/subscriptions/:external_id/alerts/:code
```

**Serializer update**
After writing openapi specs, I realize that `deleted_at` and
`updated_at` shouldn't be serialized.
Also, I recently changed `billable_metric_id` to `billable_metric.code`.
Now, since we load the billable metric, I believe we should return the
full object instead of asking the user to use this code to call again.
diegocharles pushed a commit that referenced this pull request Jun 2, 2025
Alerts were recently introduced in #3554 

This PR adds Rest API endpoints to manage the alerts.

```
GET    /api/v1/subscriptions/:external_id/alerts
POST   /api/v1/subscriptions/:external_id/alerts
GET    /api/v1/subscriptions/:external_id/alerts/:code
PUT    /api/v1/subscriptions/:external_id/alerts/:code
DELETE /api/v1/subscriptions/:external_id/alerts/:code
```

**Serializer update**
After writing openapi specs, I realize that `deleted_at` and
`updated_at` shouldn't be serialized.
Also, I recently changed `billable_metric_id` to `billable_metric.code`.
Now, since we load the billable metric, I believe we should return the
full object instead of asking the user to use this code to call again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants