[Majyles]

What
Adds GET /alerts/all/fromdate/count-per-day so that the History calendar (pyronear/new-pyro-platform#308) gets its daily alert counts in one request instead of one per day.

How (as agreed in #719)

• from_date / to_date (inclusive), at most 62 days: a month calendar shows at most 6 weeks, and this bounds the per-day risk lookups. Inverted or longer periods → 422.
• tz: IANA timezone used to split the days, UTC by default to match /alerts/all/fromdate. Unknown timezone → 422. (tz on /all/fromdate is left out of scope, as discussed.)
• Same alerts as /alerts/all/fromdate/count: organization scoping (admins see all), and the risk filter of each day, or the risk_score override. The per-day risk scores are fetched concurrently, and days sharing the same scores are counted by a single grouped query (a single query when the risk API is not configured).
• Response: [{"date": "2026-10-23", "count": 2}, …], only days with alerts.

Tests

• Per-day counts, organization scoping, admin view, consistency with /all/fromdate/count, and a tz case where 23:30 UTC falls on the next day in Paris.
• Validation: inverted period, 63 days vs 62, unknown timezone, missing parameter, unauthenticated.
• Risk filter applied day by day (mocked risk API, one lookup per day with the organization), and the risk_score override skipping the risk API.

Full suite, ruff and ty pass locally. Also tried in pyro-envdev against the demo alerts.

Note
The response field is date, consistent with from_date / to_date; in the schema it is typed dt.date since a field named date would otherwise shadow the type for Pydantic.

Closes #719

Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.96%. Comparing base (68bde16) to head (0f756dc).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #724      +/-   ##
==========================================
+ Coverage   94.87%   94.96%   +0.08%     
==========================================
  Files          60       60              
  Lines        3278     3335      +57     
==========================================
+ Hits         3110     3167      +57     
  Misses        168      168              

Flag	Coverage Δ
backend	95.12% <100.00%> (+0.08%)	⬆️
client	91.30% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[MateoLostanlen]

Thanks, the approach matches what we agreed in #719. A few things before merging:

Blocking

1. The 62-day cap is checked after the day list is built. days is built for the whole range first, so from_date=0001-01-01&to_date=9999-12-31 creates ~3.65M dates before returning 422. Could you check (to_date - from_date).days + 1 > MAX_COUNT_PER_DAY_PERIOD before building the list?

2. No index-friendly filter on started_at. The queries only filter on date(timezone(tz, timezone('UTC', started_at))) IN (...), so each one scans all of the organization's alerts (all alerts for admins). FWI classes change most days, so grouping by identical scores rarely helps: a month can mean ~30 sequential queries, each a full scan. Adding Alert.started_at >= start AND < end (the period bounds converted from tz to UTC in Python) would fix it.

3. Up to 62 concurrent risk API calls. Each call opens a new httpx.AsyncClient, and a failure or timeout returns {}, so that day is counted with no risk filter and no error. The calendar can then disagree with /all/fromdate/count for that day. A semaphore and one shared client (as in #708) would make this safer.

Non-blocking

• tz is checked with Python's zoneinfo, but the conversion runs in Postgres, which uses its own timezone database. A name Python accepts but Postgres doesn't would give a 500 instead of a 422.
• Risk scores are also fetched for days after today. For the current month's calendar that can be ~30 wasted calls; we could clip the period to today in tz.
• The sequence filter (AlertSequence join + max_conf_filter_clause) is copied from _build_alerts_from_date_stmt. Since the goal is the same alerts as /all/fromdate/count, a small shared helper would stop the two from drifting apart.
• Telemetry is sent before validation, so rejected requests are counted too.
• raise HTTPException(...) in the except should be from None (ruff B904, "B" is enabled).
• Nit: _user_auth in the tests does what the existing tests do inline with pytest.get_token(...). Could we use one style or the other in this file?

[Majyles]

Thanks a lot for the thorough review, and for catching these: some of them were basic slips on my side. All points are addressed:

Blocking

1. Day-count cap: the period length is now checked on the dates themselves, before building the day list (a test sends 0001-01-01 → 9999-12-31).
2. Index-friendly filter: the query now only selects started_at on a plain UTC range, and the alerts are counted per local day in Python. The day boundaries come from zoneinfo (DST included), so the timezone is handled in a single place and Postgres no longer converts anything. I kept the per-day bucketing in Python rather than in SQL since Python needs the timezone anyway (to clip to today and pick the risk days), which also avoids the zoneinfo/Postgres mismatch (e.g. localtime is accepted by zoneinfo but unknown to Postgres, and Postgres reads UTC+2 as UTC-2). Note that alerts.started_at has no index today: would you like a migration adding one (e.g. on (organization_id, started_at)), here or in a separate PR?
3. Risk API concurrency: RiskService now keeps a shared httpx.AsyncClient (closed in the app lifespan, as in perf(temporal): reuse the prediction HTTP client #708) and bounds concurrent calls with a semaphore (8). I kept the fail-open behaviour on errors ({} → no filter for that day), consistent with /all/fromdate and the service docstring; happy to change it if you'd rather fail the request. Side question: does the risk API offer a range endpoint (scores between two dates)? A single call per request would be even better.

Non-blocking

• tz validation: solved by the above.
• Future days: the period is clipped to today in tz, so no risk lookup for future days (tested).
• Duplicated sequence filter: extracted into _filter_alerts_by_sequences(), used by both /all/fromdate(/count) and this endpoint.
• Telemetry: moved after validation.
• Exception chaining: added from None. (FYI, B904 is in the ruff ignore list as raise-without-from-inside-except, which is why it wasn't flagged.)
• Tests: back to inline pytest.get_token(...) like the rest of the file.

I also merged main (import conflict with #714 in the tests). Full suite, ruff and ty pass locally.

[MateoLostanlen]

Thanks, all points are addressed, and the Python-side bucketing is a nice way to settle the zoneinfo/Postgres mismatch. Approving.

On your questions:

• Index: yes, please add it in this PR, on (organization_id, started_at). The table has no index at all today, so without it the range filter is still a full scan.
• Risk API range endpoint: not yet, only /scores/{day}. Tracked in MateoLostanlen/pyro-risk-api#2 (all the more since /scores/{day} computes missing days on the fly and can hit the 5s timeout on a month never queried before), then we can switch this endpoint to a single call in a follow-up.
• Fail-open: keep it, consistent with /all/fromdate.

The triage job failure is the labeler lacking write permission on fork PRs, unrelated to this change.

[MateoLostanlen]

Thanks, all points are addressed, and the Python-side bucketing is a nice way to settle the zoneinfo/Postgres mismatch. One change left before merging, see the index below.

On your questions:

• Index: yes, please add it in this PR, on (organization_id, started_at). The table has no index at all today, so without it the range filter is still a full scan.
• Risk API range endpoint: not yet, only /scores/{day}. Tracked in MateoLostanlen/pyro-risk-api#2 (all the more since /scores/{day} computes missing days on the fly and can hit the 5s timeout on a month never queried before), then we can switch this endpoint to a single call in a follow-up.
• Fail-open: keep it, consistent with /all/fromdate.

The triage job failure is the labeler lacking write permission on fork PRs, unrelated to this change.

Posted with the wrong state, the index is a change request. Re-posted below.