fix(radar): handle empty/unknown VCP without aborting station processing#123
Merged
Conversation
GetMode now returns a fallback "Unknown (VCP %q)" label and the ErrUnknownVCP sentinel for empty or unrecognized VCP codes. FetchData treats this as a soft condition: logs a WARN and continues with the fallback so the rest of the station data (status, generator state, operability) still gets processed and compared. Also drops the redundant radar.GetMode() call in monitor.processStation that re-derived the same mode FetchData had already populated; the duplicate call would have re-raised the same hard error and defeated the soft-handle. Closes #121 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Introduce VCPInfo {Mode, Description} and a package-level vcpCatalog
map keyed by VCP code. GetMode now does a map lookup; GetVCPInfo is
added so callers can surface the description (mode cycle, scan pattern
notes) for richer logs/notifications later.
The catalog populates the meaning of each known VCP inline as
structured data rather than only as comments.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The compare path had its own hand-rolled VCP→prose map (getVCPDescription) parallel to vcpCatalog. Adding a new VCP required edits in two places, with no compiler help to keep them in sync. Add an AlertText field to VCPInfo and populate it for each catalog entry; CompareData now uses GetVCPInfo to look up the alert text. The prose surfaced to Pushover is unchanged for all current VCPs: R31, R35 -> "Clear Air Mode Active" R12, R212 -> "Precipitation Mode Active" R112 -> "Precipitation Mode (Velocity Scanning Emphasis) Active" R215 -> "Precipitation Mode (Vertical Scanning Emphasis) Active" Unknown VCPs continue to fall through to "Radar mode changed from X to Y". Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
🎉 This PR is included in version 2.12.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This was referenced May 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three-commit branch resolving #121 plus tightening the VCP data layer it touched.
fix(radar): handle empty/unknown VCP without aborting station processing(c623fe0)ErrUnknownVCPsentinel;GetModereturns("Unknown (VCP %q)", wrapped sentinel)for empty/unknown codesFetchDatacheckserrors.Is(err, ErrUnknownVCP)→ logs WARN with the raw VCP and continues, so status/generator/operability still get processedradar.GetMode()call inmonitor.processStationthat would have re-raised the hard error and defeated the soft-handlerefactor(radar): replace VCP switch with typed catalog map(e2a91ff)VCPInfo {Mode, Description}and a package-levelvcpCatalogmap keyed by VCP codeGetModeis now a map lookup; newGetVCPInfoexposes the description for richer logging/alertsrefactor(radar): fold getVCPDescription into vcpCatalog as AlertText(dbce801)AlertTexttoVCPInfoand removes the parallel hand-rolledgetVCPDescriptionmap incompare.goCompareDatanow usesGetVCPInfoto surface the alert proseWhy
Production prod log on 2026-05-05 14:11 UTC:
level=ERROR msg="Failed to process station: error fetching radar data for station KATX: unknown mode for VCP -- please update code"— KATX returned an empty VCP from NWS, causing the entire station's poll cycle to be aborted at ERROR level. Empty VCP is a transient/benign state; other fields still carry useful state and should continue to be compared.Pushover behavior preview (verified against this branch)
Startup
KATX Seattle - Precipitation Mode(R212)KATX Seattle - Clear Air Mode(R31)KATX Seattle - Unknown (VCP "") Mode(empty VCP, post-fix)Change (title:
KATX Update)R31 → R212:Precipitation Mode ActiveR12 → R215:Precipitation Mode (Vertical Scanning Emphasis) ActiveR212 → R112:Precipitation Mode (Velocity Scanning Emphasis) ActiveR45):Radar mode changed from R212 to R45from X to Ystrings, unchangedTest plan
go test ./...— all packages passgo vet ./...— cleanTestGetModeextended for empty / whitespace /R99(assertserrors.Is(err, ErrUnknownVCP)+ fallback label contains the raw VCP)TestGetVCPInfocovers known + unknown pathscompare_test.goassertions on"Precipitation Mode Active"/"Clear Air Mode Active"continue to pass after the catalog refactorCloses #121