Evaluate metric-alert groups with a concurrency pool#8213
Evaluate metric-alert groups with a concurrency pool#8213jonathanawesome wants to merge 1 commit into
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the metric alert rules evaluation task to use a fixed-capacity concurrency pool via the p-limit library, replacing the previous batch-based chunking approach. This allows groups to be processed continuously without waiting for an entire batch to complete, improving throughput when some groups are slower than others. I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
🐋 This PR was built and pushed to the following Docker images: Targets: Platforms: Image Tags: |
jdolle
left a comment
jdolle
left a comment
There was a problem hiding this comment.
please add a changeset is all
2 participants
This PR replaces the fixed-batch barrier in the
evaluateMetricAlertRulescron with ap-limitconcurrency pool, so metric-alert groups are evaluated with continuous bounded parallelism instead of synchronized batches of 5.Before, a batch couldn't start until the previous one fully drained, so one slow group (like a timed-out ClickHouse query) idled the other slots and delayed every later group, including cheap ones from other orgs; the pool keeps up to 5 groups in flight at all times, starting the next as soon as one finishes.
Behavior is otherwise unchanged: same cap (still below the Postgres pool size), same
allSettledfailure isolation, and the same batchedlast_evaluated_atupdate once all groups drain.p-limitis the limiter already used by the usage and migrations packages.