-
Notifications
You must be signed in to change notification settings - Fork 1.4k
MONGOID 5800 When initializing an embedded association with an invalid hash, got undefined method `with_indifferent_access' error #6075
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR addresses a regression in Mongoid 8.0 where passing a single hash instead of an array of hashes to an embeds_many association raises an undefined method 'with_indifferent_access' error. The fix adds backwards compatibility by detecting when an array element doesn't respond to with_indifferent_access and converting it to a hash before processing.
Key changes:
- Added fallback logic to handle array elements that need conversion to hashes
- Introduced test coverage for the edge case of passing a hash to an
embeds_manyassociation
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| spec/integration/associations/embeds_many_spec.rb | Added test cases verifying that passing a hash instead of an array to an embeds_many association doesn't raise errors |
| lib/mongoid/association/nested/many.rb | Added conditional logic to convert non-hash-like array elements to hashes before calling with_indifferent_access |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| elsif attrs[1].respond_to?(:with_indifferent_access) | ||
| process_attributes(parent, attrs[1].with_indifferent_access) | ||
| else | ||
| process_attributes(parent, Hash[*attrs].with_indifferent_access) |
Copilot
AI
Dec 12, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using Hash[*attrs] assumes attrs is an array with an even number of elements (key-value pairs). If attrs has an odd number of elements, this will raise an ArgumentError. Add validation or rescue logic to handle malformed input gracefully.
| process_attributes(parent, Hash[*attrs].with_indifferent_access) | |
| if attrs.respond_to?(:to_a) && attrs.to_a.length.even? | |
| process_attributes(parent, Hash[*attrs].with_indifferent_access) | |
| else | |
| # Malformed input: skip or handle as needed | |
| # Optionally, log a warning here | |
| next | |
| end |
| elsif attrs[1].respond_to?(:with_indifferent_access) | ||
| process_attributes(parent, attrs[1].with_indifferent_access) | ||
| else | ||
| process_attributes(parent, Hash[*attrs].with_indifferent_access) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need more guards here in case it can't be cast to a hash?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's probably smart to check that array has an even number of elements, before creating a hash from it. I think an empty Hash is okay here -- I can imagine someone doing Person.new(children: {}) (thus creating a new person with a single child).
We should probably also raise an exception in the final else clause, so that we never have data being silently ignored. A simple ArgumentError would probably suffice, indicating that the arguments aren't supported or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed - I didn't add any extra testing for this, I can't think of any scenarios where an uneven number of fields would be provided, but I agree that it's a good thing to check for.
…goid into MONGOID-5800
jamis
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good solution, handling an edge case that we hadn't considered. As the OP noted in the ticket, this is technically not valid data, but if someone ran into this, and if we can handle the situation gracefully, we might as well.
| elsif attrs[1].respond_to?(:with_indifferent_access) | ||
| process_attributes(parent, attrs[1].with_indifferent_access) | ||
| else | ||
| process_attributes(parent, Hash[*attrs].with_indifferent_access) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's probably smart to check that array has an even number of elements, before creating a hash from it. I think an empty Hash is okay here -- I can imagine someone doing Person.new(children: {}) (thus creating a new person with a single child).
We should probably also raise an exception in the final else clause, so that we never have data being silently ignored. A simple ArgumentError would probably suffice, indicating that the arguments aren't supported or something.
Currently, if a document with an
embeds_manyrelationship is created with the embedded field set to a single hash, instead of an array of hashes, an error is raised withundefined method 'with_indifferent_access'. This behavior is new in 8.0. This PR allows backwards compatibility by checking if a value has the methodwith_indifferent_access, and, if not, we can assume it is an array that should be a hash. We convert it to a hash and callwith_indifferent_accesson the result.