BugFix: '<attribute>' and '<attribute>_id' conflict. #1709
Merged
+319
−46
Conversation
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
This was referenced Oct 28, 2024
CodeMeister
changed the title
|
I had expected this problem to be much more difficult to resolve, but can't find anything wrong with your code, good job 🙌 When trying to understand the conflict ignored attributes - that as far as I've seen only applies to transient ones - makes the processing hard to understand. I think you managed well to make this easier to grasp. |
DTrejo
reviewed
Mar 8, 2025
| end | ||
|
|
||
| def hash_instance_methods_to_respond_to | ||
| @attribute_list.names + override_names + @build_class.instance_methods |
There was a problem hiding this comment.
use attribute_names? side note: just lost a number of hours on the bug this PR will solve 😢 , thank you for working to fix it! 🎉
Contributor
Author
There was a problem hiding this comment.
CodeMeister
force-pushed
the
attribute-alias-filtering
branch
from
832cfe7 to
3dde8e6
Compare
- AttributeAssigner refactored to ignore a
matching attribute alias, if it also
matches the name of another attribute.
- Tests added for attribute assignment.
- Gemfile update from rebasing on main.
neilvcarvalho
force-pushed
the
attribute-alias-filtering
branch
from
3dde8e6 to
d6fe17d
Compare
neilvcarvalho
force-pushed
the
attribute-alias-filtering
branch
from
d6fe17d to
44eace5
Compare
neilvcarvalho
approved these changes
Jul 25, 2025
Member
neilvcarvalho
left a comment
neilvcarvalho
left a comment
There was a problem hiding this comment.
Hey @CodeMeister - I took the liberty of improving the acceptance specs related to aliases, and added the edge case test you implemented.
Thank you so much for the great solution. It was very elegant.
vburzynski
approved these changes
Jul 25, 2025
JinOketani
added a commit
to JinOketani/factory_bot
that referenced
this pull request
Sep 12, 2025
…tbot#1767) * Ensure association overrides take precedence over trait-defined foreign keys In 6.5.5, changes related to PR thoughtbot#1709 introduced an unintended behavior where a trait-defined `*_id` could take precedence over an explicit association override. This could lead to inconsistency between the association and its foreign key. * Update `AttributeAssigner#aliased_attribute?` to prioritize associations When an association override is provided (e.g., `user: user_instance`), the corresponding trait-defined foreign key is ignored, keeping the object graph consistent with Rails/ActiveRecord expectations. The fix preserves the intent of PR thoughtbot#1709 regarding attribute/attribute_id conflicts. * Add regression specs - Association override wins over trait-defined foreign key - Trait-defined foreign key applies when no association override is present - Multiple foreign-key traits remain supported Example: Before (6.5.5): FactoryBot.build(:post, :with_user_id_999, user: user).user_id # => 999 After (this change; consistent with 6.5.4): FactoryBot.build(:post, :with_user_id_999, user: user).user_id # => user.id Related: thoughtbot#1709, thoughtbot#1767 --------- Co-authored-by: Jin Oketani <b1506231@planet.kanazawa-it.ac.jp>
JinOketani
added a commit
to JinOketani/factory_bot
that referenced
this pull request
Sep 12, 2025
…tbot#1767) * Ensure association overrides take precedence over trait-defined foreign keys In 6.5.5, changes related to PR thoughtbot#1709 introduced an unintended behavior where a trait-defined `*_id` could take precedence over an explicit association override. This could lead to inconsistency between the association and its foreign key. * Update `AttributeAssigner#aliased_attribute?` to prioritize associations When an association override is provided (e.g., `user: user_instance`), the corresponding trait-defined foreign key is ignored, keeping the object graph consistent with Rails/ActiveRecord expectations. The fix preserves the intent of PR thoughtbot#1709 regarding attribute/attribute_id conflicts. * Add regression specs - Association override wins over trait-defined foreign key - Trait-defined foreign key applies when no association override is present - Multiple foreign-key traits remain supported Example: Before (6.5.5): FactoryBot.build(:post, :with_user_id_999, user: user).user_id # => 999 After (this change; consistent with 6.5.4): FactoryBot.build(:post, :with_user_id_999, user: user).user_id # => user.id Related: thoughtbot#1709, thoughtbot#1767
vburzynski
added a commit
that referenced
this pull request
Oct 16, 2025
* Respect association overrides over trait-defined foreign keys (#1767) * Ensure association overrides take precedence over trait-defined foreign keys In 6.5.5, changes related to PR #1709 introduced an unintended behavior where a trait-defined `*_id` could take precedence over an explicit association override. This could lead to inconsistency between the association and its foreign key. * Update `AttributeAssigner#aliased_attribute?` to prioritize associations When an association override is provided (e.g., `user: user_instance`), the corresponding trait-defined foreign key is ignored, keeping the object graph consistent with Rails/ActiveRecord expectations. The fix preserves the intent of PR #1709 regarding attribute/attribute_id conflicts. * Add regression specs - Association override wins over trait-defined foreign key - Trait-defined foreign key applies when no association override is present - Multiple foreign-key traits remain supported Example: Before (6.5.5): FactoryBot.build(:post, :with_user_id_999, user: user).user_id # => 999 After (this change; consistent with 6.5.4): FactoryBot.build(:post, :with_user_id_999, user: user).user_id # => user.id Related: #1709, #1767 * Add clarifying comment for association override precedence Adds a comment explaining why association overrides take precedence over trait-defined foreign keys in AttributeAssigner#aliased_attribute?. * fix: addresses regression in attribute assignment factory_bot v6.5.5 included a patch which worked around the previous limitaion of not being able to assign both <attribute> and <attribute>_id as independent attributes. The change introduced regressions into how attributes are assigned. This commit fixes regressions involving declared attributes which are aliases of overrides where an association is involved. It fixes behavior where the attributes are not assigned in the expected manner as well as fixes an instance where an extra erroneous associated object is created. * fix: correct specs for Rails 6.1 --------- Co-authored-by: Valerie Burzynski <valerie.burzynski@thoughtbot.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Fixes: #1680
Fixes: #1142
Addresses: #1708
When a factory has both <attribute> and <attribute>_id, each one is considered an alias for the other
and are not assigned correctly.
This request eliminates this issue by checking if the override is an existing attribute name, before matching against an alias.
It works for any recorded aliases, not just '_id'.