Fix #700: Support custom string-based map key types in DefaultResolveFn

[cobyfrombrooklyn-bot]

DefaultResolveFn panicked with reflect.Value.MapIndex: value of type string is not assignable to type X when resolving fields from maps with custom string-based key types like:

type TranslationKey string
type Translation map[TranslationKey]string

The issue is that reflect.ValueOf(p.Info.FieldName) creates a string value, but the map expects a TranslationKey key. Go reflection requires exact type matching for MapIndex.

Fix

Convert the field name to the map's actual key type using reflect.Value.Convert(r.Type().Key()) before calling MapIndex. This is safe because we already check that the key kind is reflect.String.

Test

Added TestDefaultResolveFn_MapWithCustomStringKeyType that creates a schema using map[TranslationKey]string as the source data and verifies fields are resolved correctly. Without the fix, the test fails with the MapIndex panic. With the fix, it passes.

Full test suite passes. Tested locally on macOS ARM (Apple Silicon).

Fixes #700

Summary by CodeRabbit

• Bug Fixes

  • Fixed field access on maps with custom string-like key types. The resolver now correctly converts field names to the appropriate key type before indexing, enabling support for custom key types while preserving existing behavior for standard strings.

• Tests

  • Added regression test ensuring correct field resolution behavior for maps with custom string-based key types.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d5f8f3c and e87de74.

📒 Files selected for processing (2)

• executor.go
• executor_test.go

---

📝 Walkthrough

Walkthrough

Fixes DefaultResolveFn to properly resolve map fields when the map uses custom string-based key types (e.g., type MyKey string). The fix converts field names to the map's key type before indexing, enabling support for custom key types while maintaining existing behavior for standard string maps.

Changes

Cohort / File(s)	Summary
Map Key Type Handling executor.go	Adds type conversion logic to convert field names to the map's key type before indexing, resolving map access failures with custom string-based key types.
Regression Test executor_test.go	Adds TestDefaultResolveFn_MapWithCustomStringKeyType to verify DefaultResolveFn correctly resolves nested fields in maps with custom string-based key types.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A rabbit hops through maps of key,
Custom strings now work with glee!
No more errors, no more strife,
Type conversion saves the day—cheers to life! 🥕

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title accurately summarizes the main change: adding support for custom string-based map key types in DefaultResolveFn, with issue reference #700.
Linked Issues check	✅ Passed	The pull request directly addresses issue #700 by implementing the desired fix: converting field names to the map's actual key type before MapIndex calls, enabling maps with defined string-based key types to resolve correctly.
Out of Scope Changes check	✅ Passed	All changes are within scope: executor.go implements the core fix for custom string-based map keys, and executor_test.go adds a regression test covering the exact issue scenario.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}