fix(session): accept value matching any band on multi-RANGE DATA#16
Merged
Conversation
validateAgainstRange used to read only Data.Range (the single-band field kept for back-compat) and refuse anything outside it. For DATA declarations with several <RANGE> children — piecewise-valid bands with different step sizes, e.g. VLineaPrimario_1 declaring [50..499 step 1] / [500..4990 step 10] / [5000..49900 step 100] / [50000..500000 step 1000] — the validator effectively saw only the last band and rejected legitimate values from any other. The catalog parser already populates Data.Ranges with every <RANGE> child (kept the back-compat Data.Range = first band on the side). Switch the validator to consult Data.Ranges when populated, fall back to the single Range otherwise, and accept the value if it sits inside *any* band — both bounds and step alignment checked per-band. The error path now distinguishes single-band (preserves the original "out of catalog range [Min, Max]" wording for callers/operators used to it) from multi-band (lists every band so the operator can see what's actually allowed). Tests cover: single-band accept/reject/step-violation; multi-band accept inside each band, reject below/above, reject when value is inside one band's bounds but violates its step; non-numeric TIPOs skipped; absent ranges no-op. Closes #2 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Closes #2.
What changed
validateAgainstRangenow consultsData.Ranges(the full set of<RANGE>children, populated by the parser since the audit-D2 changes) and accepts a value matching any band, instead of only the last<RANGE>declared. The single-bandData.Rangeis still read as a fallback for DATA with exactly one<RANGE>.Per-band checks remain the same as before —
Min ≤ value ≤ Maxand(value − Min) mod Step == 0whenStep > 1— they're just run against each band in turn until one matches.The error path branches:
out of catalog range [Min, Max]/violates step=K (offsets from Min allowed)) so existing tooling/error-parsing keeps working;not in any of catalog bands [a,b step c] [d,e step f] …) so the operator can see what the catalog actually allows.Tests
pkg/session/range_internal_test.go(new, in-package so the private function is callable). Covers:[Min, Max]but violating itsSteprejected (no fallthrough);STRING/ENUM*TIPOs skipped (existing behaviour preserved);RangenorRangesis a no-op.The catalog parser side was already correct (commit 5e28fc9 added
Rangesand the loop that appends every<RANGE>child); this PR only fixes the validator that ignored it.Scope
I did not extend the test fixture
testdata/us/TEST-VB0-awith a multi-band DATA + an end-to-endSession.Setintegration test. The internal-package tests exercise the failing function directly with a synthesised*catalog.Data, which is enough to lock in the fix; a fixture-level integration test is a reasonable follow-up if we want to assert the parser+validator interaction together.🤖 Generated with Claude Code