Associations cannot override trait-defined ID attributes since v6.5.5

[oehlschl]

Description

#1709 introduces surprising behavior, particularly for Rails apps, where associations can no longer override traits that set those associations by ID. This is is particularly surprising in the Rails case, where developers can generally expect setting association IDs and associations themselves to behave similarly.

There may be a best-practices argument for encouraging developers to not set both the ID and association attributes, but without a way of enforcing that, it's not a particularly scalable solution, and unfortunately the failure mode for this new behavior isn't terribly obvious.

Reproduction Steps

Here's the modified reproduction script. This test passes in 6.5.4 but fails in 6.5.5.

require "bundler/inline"

gemfile(true) do
  source "https://rubygems.org"
  git_source(:github) { |repo| "https://github.com/#{repo}.git" }
  gem "factory_bot", "~> 6.0"
  gem "activerecord"
  gem "sqlite3"
end

require "active_record"
require "factory_bot"
require "minitest/autorun"
require "logger"

ActiveRecord::Base.establish_connection(adapter: "sqlite3", database: ":memory:")
ActiveRecord::Base.logger = Logger.new(STDOUT)

ActiveRecord::Schema.define do
  create_table :users, force: true do |t|
    t.string :name
  end
  
  create_table :posts, force: true do |t|
    t.string :body
    t.integer :user_id
  end
end

class User < ActiveRecord::Base
end

class Post < ActiveRecord::Base
  belongs_to :user
end

FactoryBot.define do
  factory :user do
    name { "Test User" }
  end
  
  factory :post do
    body { "Post body" }
    association :user
    
    trait :with_system_user_id do
      user_id { 999 }
    end
  end
end

class FactoryBotTest < Minitest::Test
  def test_association_overrides_trait_user_id
    # This test passes in 6.5.4 but fails in 6.5.5
    user = FactoryBot.create(:user)
    post = FactoryBot.build(:post, :with_system_user_id, user: user)
    
    assert_equal user.id, post.user_id, 
      "Association should override trait's user_id. Got #{post.user_id} instead of #{user.id}"
  end
end

Expected behavior

We expect post.user_id to be user.id and not 999

Actual behavior

post.user_id is still the ID set in the trait (999)

System configuration

factory_bot version: 6.5.5
rails version: 7.1
ruby version: 3.4.5

[CodeMeister]

Hi @oehlschl,

Not sure I understand the issue clearly.

I would expect defining any attribute, within a trait or not, to set the attribute's value regardless of any associations. If I set an ID to '999' and it's then replaced by the factory with the association's ID, I would find that illogical.

When working with Rails:

• If I build :post, user: @user I expect the factory to not create a new association, but set user_id to @user.id.
• I expect build :post, user_id: @user.id to be the same.
• I expect any trait that sets the user_id to be ignored if I have provided the ID value.
• I expect any trait that sets the user_id to be applied if I didn't supply a value.
• If the user_id is not set by me, or a trait, only then would I expect the association to be triggered.

What am I missing?

[oehlschl]

Hopefully this is clearer @CodeMeister.

This isn't about automatic association behavior as much as it's about explicit override precedence.

When I write: build(:post, :with_system_user_id, user: @user), then @user is an explicit override that I'm passing at build time. It should override the trait's default user_id: 999, just like any explicit value overrides trait defaults.

I think that's what people expect, since Rails models work the same way; if I set post.user_id = 1 and do post.assign_attributes(user: @user), then post.user_id should be @user.id and not whatever it was before.

This worked in 6.5.4 (explicit overrides always won / matches Rails model behavior) but broke in 6.5.5 (trait wins over explicit override in this case / no longer matches Rails model behavior).

[oehlschl]

You could make an argument that user_id and user are technically different attributes, but FactoryBot has so far treated associations and their foreign keys as aliases of each other for override purposes.

Things suggesting this was intentional FactoryBot behavior:

1. The code explicitly handles this: FactoryBot's Association class has an alias_for? method that returns true for the foreign key. The AttributeAssigner uses this to handle overrides.
2. It works in the reverse direction: In both 6.5.4 AND 6.5.5, if a trait sets user and you override with user_id, it works correctly:

trait :with_user do
  user { create(:user) }  # Sets association
end

build(:post, :with_user, user_id: 999)  # user_id override works in both versions

3. The regression is asymmetric: If these were truly independent attributes, the behavior would be consistent in both directions. But only one direction broke.
4. As mentioned above, Rails/ActiveRecord treats them as linked: When you set user=, ActiveRecord sets user_id. When you set user_id=, ActiveRecord clears/updates user. They're not independent, but rather two interfaces to the same relationship / attribute.
5. This breaks existing test suites: This was working behavior that codebases may rely on. The change in 6.5.5 breaks the principle of least surprise.

[CodeMeister]

@oehlschl thanks, that makes it clearer 👌. I'll have to look and see what's going on 🔎

[oehlschl]

Cool, thanks very much. I don't know what the right solution here is, but I did want to surface it after it tripped us up in a bundle update yesterday. Appreciate your contributions and the attention to this.