Description

Today, the Codegate ui queries all alerts in a workspace and filters/counts alerts with different criteria to produce a "summary" UI.

This has a downside in that it is slow to query all alerts in a workspace containing a lot of data. Most of the data in the response is discarded, so it is an unnecessarily large query.

The task here is to add a new endpoint that summarises the counts of alerts per-type — that can drive the UI in the attached screenshot.

I think the north star would be a response payload like this:

GET /api/v1/workspaces/:workspace_name/alerts-summary

{
    "codegate-malicious-package": 14,
    "codegate-pii": 10,
    "codegate-secrets": 21,
}

In the above example, each key in the response is a trigger_type on an Alert.

I predict at least one snag, which is that there is no exact trigger_type for malicious packages in the existing response payload from GET /api/v1/workspaces/:workspace_name/alerts.

An alert warning of a malicious package detection contains 2 fields, trigger_string and trigger_type:

{
  "trigger_string": {
    "name": "invokehttp",
    "type": "pypi",
    "status": "malicious",
    "description": "Python HTTP for Humans."
  },
  "trigger_type": "codegate-context-retriever"
}

In the UI codebase, we use the following logic to determine if an alert is for a malicious package:

export function isAlertMalicious(alert: Alert | AlertConversation | null) {
  return (
    alert?.trigger_category === 'critical' &&
    alert.trigger_string !== null &&
    typeof alert.trigger_string === 'object' &&
    'status' in alert.trigger_string &&
    alert.trigger_string.status === 'malicious'
  )
}

So we might have to represent a malicious package as a discrete trigger_type in the SQLite DB to simplify this, or move this filtering logic into the endpoint handler.

Additional Context

No response