No description
Root cause of 14 stuck hrrr-queued contacts: hrrr_point_rs's CONUS-only grid silently writes zero profiles for out-of-bounds points (UK, Winnipeg, Alberta, >50° lat), but the fetch task still completes successfully. ContactWeatherEnqueueWorker's hrrr_placeholder_jobs always emitted a queued placeholder for any contact with a pos1, which meant mark_hrrr_status! re-flagged :queued every backfill tick forever. Introduce Propagation.Grid.contains?/1 as the canonical in-CONUS check (inclusive on all four edges, nil-safe). Use it in two places of ContactWeatherEnqueueWorker: - hrrr_placeholder_jobs/1 now returns [] for OCONUS contacts, same as pre-2014 / already-complete ones. - mark_hrrr_status!/3 empty-list clause now branches on Grid.contains? first (→ :unavailable) before falling through to the existing NARR-coverage / :complete logic. Next backfill tick will flip the 14 stuck OCONUS contacts in prod to :unavailable automatically. The remaining 13 "CONUS" stuck ones are right at the 50° edge (lat=50.1875 rounds outside the box) — same reconciliation path. Coverage additions: - Grid.contains?/1 — corner-inclusive, OCONUS positive/negative fixtures based on the actual stuck-contact pos1 values, nil/missing- key/nil-value handling. - enqueue_for_contact regression tests: pos1 in the UK and pos1 just north of the lat cap both land at :unavailable, not :queued. Suite: 2,416 tests + 159 properties (was 2,409 + 159); credo strict clean. |
||
|---|---|---|
| .forgejo/workflows | ||
| .github | ||
| assets | ||
| bin | ||
| config | ||
| docs | ||
| k8s | ||
| lib | ||
| lib_ml | ||
| notebooks | ||
| priv | ||
| rel | ||
| rust/prop_grid_rs | ||
| scripts | ||
| test | ||
| vendor | ||
| .credo.exs | ||
| .dockerignore | ||
| .formatter.exs | ||
| .gitignore | ||
| .tool-versions | ||
| AGENTS.md | ||
| algo.md | ||
| app.json | ||
| CLAUDE.md | ||
| Dockerfile | ||
| elevation.md | ||
| LICENSE | ||
| mix.exs | ||
| mix.lock | ||
| prediction.md | ||
| README.md | ||
| tail_logs.sh | ||
| updates.md | ||
Microwaveprop
To start your Phoenix server:
- Run
mix setupto install and setup dependencies - Start Phoenix endpoint with
mix phx.serveror inside IEx withiex -S mix phx.server
Now you can visit localhost:4000 from your browser.
Ready to run in production? Please check our deployment guides.
Learn more
- Official website: https://www.phoenixframework.org/
- Guides: https://hexdocs.pm/phoenix/overview.html
- Docs: https://hexdocs.pm/phoenix
- Forum: https://elixirforum.com/c/phoenix-forum
- Source: https://github.com/phoenixframework/phoenix