Capture radar frames at the configured interval, not every other run (#208) #209

Merged

claude-bot merged 1 commit from fix/radar-frame-cadence into main

2026-10-13 21:25:18 +00:00

claude-bot commented

2026-10-13 21:17:49 +00:00

Collaborator

Fixes #208.

The bug

ALERT_RADAR_FRAME_INTERVAL_MINUTES is 5, but frames arrive every ten minutes. On dev, two Flood Watches collected 23 frames between 17:29Z and 21:05Z on 2026-10-13.

The capture job is scheduled at the same period as the interval it enforces. A frame's captured_at is stamped when it is stored, a second or two after its run began, so on the next run it is about 4m58s old. The gate read that as "younger than five minutes" and skipped it. Every alert was captured on alternate runs.

The fix

_due_after() gives the age a frame must reach before another is captured: the interval less one minute of jitter allowance, with the allowance capped at half the interval. At the default setting a frame is due after four minutes, so a job running every five captures every run.

The alert-time snapshot still behaves: it lands at an arbitrary moment, and a job run two minutes later does not add a second frame.

What changes in practice

A 45-minute warning yields about 9 frames instead of 4 or 5, so the Explorer loop (#140) shows storm motion at the resolution it was designed for.
The 24-frame cap is unchanged, and now spans two hours rather than four. Warnings are short and lose nothing. A long-lived watch loses frames from its later hours. Raising the cap is a disk decision and is left to #158.
Outbound load on NOAA's MapServer per active alert doubles in rate, to what the setting always said, and totals the same 24 fetches per alert.

Verification

ruff: clean
Bulk tier: 1015 passed (3 new)
The new "one job period old is due" test fails with the fix reverted and passes with it.
Postgres tier: left to CI.

🤖 Generated with Claude Code

Fixes #208. ## The bug `ALERT_RADAR_FRAME_INTERVAL_MINUTES` is 5, but frames arrive every ten minutes. On dev, two Flood Watches collected 23 frames between 17:29Z and 21:05Z on 2026-10-13. The capture job is scheduled at the same period as the interval it enforces. A frame's `captured_at` is stamped when it is stored, a second or two after its run began, so on the next run it is about 4m58s old. The gate read that as "younger than five minutes" and skipped it. Every alert was captured on alternate runs. ## The fix `_due_after()` gives the age a frame must reach before another is captured: the interval less one minute of jitter allowance, with the allowance capped at half the interval. At the default setting a frame is due after four minutes, so a job running every five captures every run. The alert-time snapshot still behaves: it lands at an arbitrary moment, and a job run two minutes later does not add a second frame. ## What changes in practice - A 45-minute warning yields about 9 frames instead of 4 or 5, so the Explorer loop (#140) shows storm motion at the resolution it was designed for. - **The 24-frame cap is unchanged**, and now spans two hours rather than four. Warnings are short and lose nothing. A long-lived watch loses frames from its later hours. Raising the cap is a disk decision and is left to #158. - Outbound load on NOAA's MapServer per active alert doubles in rate, to what the setting always said, and totals the same 24 fetches per alert. ## Verification - ruff: clean - Bulk tier: **1015 passed** (3 new) - The new "one job period old is due" test fails with the fix reverted and passes with it. - Postgres tier: left to CI. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-10-13 21:17:50 +00:00

Capture radar frames at the configured interval, not every other run (#208 )

CI / test (pull_request) Successful in 6m23s

Details

00e3c8e0a5

ALERT_RADAR_FRAME_INTERVAL_MINUTES is 5, but frames were arriving every ten
minutes: dev collected 23 between 17:29Z and 21:05Z on 2026-10-13.

The capture job runs at the same period as the interval it enforces, and a
frame is stamped when it is stored, a second or two after its run began. On
the next run that frame is 4m58s old, which the gate read as younger than
five minutes, so every alert was captured on alternate runs only.

The gate now allows for that jitter: a frame is due once it is older than
the interval less one minute, with the allowance capped at half the interval
so a short interval still blocks an immediate re-capture.

The per-event cap is unchanged at 24 frames. At a true five-minute cadence
that spans two hours rather than the four it has been covering.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

claude-bot merged commit 6d45426528 into main

2026-10-13 21:25:18 +00:00

claude-bot referenced this pull request from a commit

2026-10-13 21:25:20 +00:00

Merge pull request 'Capture radar frames at the configured interval, not every other run (#208)' (#209) from fix/radar-frame-cadence into main

claude-bot referenced this pull request

2026-10-13 21:25:25 +00:00

Radar frames are captured every 10 minutes, not the configured 5 #208

claude-bot referenced this pull request

2026-10-14 00:11:53 +00:00

Add v2.0.0-rc7 changelog entry #212