Skip to content

fix: distinguish collection and element matches when walking input - #1082

Merged
wolveix merged 1 commit into
mainfrom
fix/collection-resolver-paths
Jul 29, 2026
Merged

fix: distinguish collection and element matches when walking input#1082
wolveix merged 1 commit into
mainfrom
fix/collection-resolver-paths

Conversation

@wolveix

@wolveix wolveix commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator

Follow-up to #1076, which surfaced two silent issues in the input walker.

Resolver on a named collection type returned a 500. type Coords [2]float64 with a Resolve method: everyPB treated every collection as a container to walk through, so it stepped past the array and tried to run a resolver on each float64. The cause is that _findInType recorded the same path whether the match was on the collection's own type or on its element type. It now records a marker step when descending into elements, so both are exact and the kind-based guess is gone. This also fixes the case where a collection and its element both have resolvers, which previously ran the element's twice and the collection's never.

Defaults and resolvers reached through a map panicked with reflect: reflect.Value.Set using unaddressable value, because map values are copies. The value is now copied out, walked, then written back with SetMapIndex, so defaults and resolver mutations inside maps stick. map[string]Struct with a default: tag panics on main today, so that is fixed too.

Tests cover resolvers on named array, slice and nested collection types, collections whose elements also resolve, and defaults plus resolver mutations through maps. Each fails without these changes. Benchmarks are flat except map bodies, about 4% for the write-back.

Known limitation, not addressed here: an omitted optional [N]T field runs resolvers and defaults on N zero elements, since a Go array is always N values. That matches existing behaviour for non-pointer struct fields; []T and *[N]T work as expected.

Resolvers and defaults are found by walking the input type and recording a
path to each match. A path to a match on a collection's own type, e.g. a
resolver on `type Coords [2]float64`, was indistinguishable from a path to a
match on its element type, so `everyPB` guessed by kind: collections were
always treated as containers to walk through. Now that fixed arrays are walked
too, that guess turned a resolver on a named array type into a panic, and it
was already wrong when a collection and its element both had resolvers, running
the element's twice and the collection's never.

Record a marker step in the path when descending into a collection's elements
so both cases are exact, and drop the kind-based guess.

Values reached through a map were also visited as copies, which panicked with
`reflect: reflect.Value.Set using unaddressable value` when a default was
applied and silently discarded resolver mutations. Copy the value out, walk it,
then write it back with `SetMapIndex`.
@codecov

codecov Bot commented Jul 29, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.20%. Comparing base (5961f0a) to head (dc51cbb).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1082      +/-   ##
==========================================
- Coverage   93.22%   93.20%   -0.03%     
==========================================
  Files          23       23              
  Lines        4976     4988      +12     
==========================================
+ Hits         4639     4649      +10     
- Misses        271      272       +1     
- Partials       66       67       +1     

☔ 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.

@wolveix
wolveix merged commit 198225e into main Jul 29, 2026
6 of 7 checks passed
@wolveix
wolveix deleted the fix/collection-resolver-paths branch July 29, 2026 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant