fix: handle string-type exposure owner in ExposureSchema validation#2110
Conversation
When a dbt exposure owner is configured as a plain string (e.g., `owner: username`) instead of a dict with name/email fields, the ExposureSchema validation fails because Pydantic cannot coerce a string into an OwnerSchema. Add a pre-validator on the `owner` field that converts a string value into an OwnerSchema instance with the string as the name, matching the existing pattern used by `_load_var_to_list` for other fields. Fixes elementary-data#1732
📝 WalkthroughWalkthroughAdded a pre-validation method Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
No actionable comments were generated in the recent review. 🎉 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. Comment |
|
👋 @themavik |
Summary
When a dbt exposure owner is configured as a plain string in
dbt_project.yml:instead of the nested dict form:
the
ExposureSchemavalidation fails with a Pydantic error because it cannot coerce a string into anOwnerSchemaobject.Changes
Added a
@validator("owner", pre=True)toExposureSchemathat converts a string value into anOwnerSchema(name=<string>)instance. This follows the same defensive-parsing pattern already used by_load_var_to_listfortags,owners, anddepends_on_nodesfields.Test Plan
owner: "username"(string) should now parse correctlyowner: {name: "username", email: "x@y.com"}(dict) continues to workowner: nullcontinues to workFixes #1732
Assisted by Claude Opus 4.6 max thinking
Made with Cursor
Summary by CodeRabbit
Release Notes