Updating unrelated attributes resets serialized attribute with a wrong value in 7.1

[janklimo]

Steps to reproduce

The simplified example below shows that updating an unrelated attribute (name) of a user resets the serialized attribute value with wrong data. Reloading the record fixes the issue.

# frozen_string_literal: true

require 'bundler/inline'

gemfile(true) do
  source 'https://rubygems.org'

  git_source(:github) { |repo| "https://github.com/#{repo}.git" }

  # Activate the gem you are reporting the issue against.
  gem 'activerecord', '7.1.1' # works on 7.0.8
  gem 'sqlite3'
  gem 'pry-rails'
end

require 'active_record'
require 'minitest/autorun'
require 'logger'

# This connection will do for database-independent bug reports.
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.text :name
    t.json :cached_configuration
  end

  create_table :configurations, force: true do |t|
    t.integer :user_id
  end

  create_table :options, force: true do |t|
    t.integer :configuration_id
    t.string :key
    t.string :value
  end
end

class ConfigurationCache
  class << self
    def load(configuration_json)
      return if configuration_json.blank?

      attributes = JSON.parse(configuration_json)

      Configuration.new(attributes.except('options')).tap do |configuration|
        configuration.options = attributes['options'].map do |option_attributes|
          Option.new(option_attributes)
        end
      end
    end

    def dump(configuration)
      configuration.to_json(include: :options)
    end
  end
end

class User < ActiveRecord::Base
  has_one :configuration

  serialize :cached_configuration, coder: ConfigurationCache
end

class Configuration < ActiveRecord::Base
  belongs_to :user
  has_many :options
end

class Option < ActiveRecord::Base
  belongs_to :configuration
end

class AttributeSerializationTest < Minitest::Test
  def test_attribute_serialization
    user = User.create!(name: 'Tom')

    configuration = user.create_configuration!
    configuration.options << Option.create(key: 'key', value: 'secret')

    user.update!(cached_configuration: configuration)

    # Correctly serialized and loaded
    assert_equal configuration.id, user.cached_configuration.id
    assert_equal 1, user.cached_configuration.options.size

    # All correct – does not update serialized attribute
    user.name = 'Amanda'

    assert_equal configuration.id, user.cached_configuration.id
    assert_equal 1, user.cached_configuration.options.size

    # Wrong – updates serialized attribute with incomplete data
    user.update!(name: 'Joe')

    # user
    # => #<User:0x00000001199ac468 id: 1, name: "Joe", cached_configuration: #<Configuration:0x000000011bb0cbd0 id: nil, user_id: 1>>
    
    # user.cached_configuration.options
    # => []

    assert_equal configuration.id, user.cached_configuration.id
    assert_equal 1, user.cached_configuration.options.size

    # All good again – reloading the record fixes the serialized attribute
    user.reload

    assert_equal configuration.id, user.cached_configuration.id
    assert_equal 1, user.cached_configuration.options.size
  end
end

Expected behavior

Updating a record should not update serialized attributes.

Actual behavior

The attribute is updated with faulty data.

System configuration

Rails version: 7.1.1

Ruby version: 3.2.2

[fatkodima]

I bisected this behaviour into the 3814168 change (cc @eileencodes).

You assign an ActiveRecord record in user.update!(cached_configuration: configuration) and update! during its call chain clears dirty attributes an "forgets attribute assignment"

rails/activemodel/lib/active_model/dirty.rb

Line 270 in 392e5ef

forget_attribute_assignments

which then calls 3814168#diff-5208e586ef2714ffb46327930338aa312264b56587696a1e7fee0a6fe6642788R178-R189 which then calls dup on the ActiveRecord record 3814168#diff-5208e586ef2714ffb46327930338aa312264b56587696a1e7fee0a6fe6642788R185 which resets primary key.

[fatkodima]

The dumbest solution from the rails side is to check if the @value is not an ActiveRecord::Base instance and do not call that dup, but I am not sure this is the correct solution.

[eileencodes]

This is the actual change #46282. I reverted it while we were debugging a Rails upgrade and then unreverted it. cc/ @jonathanhefner

[jonathanhefner]

@fatkodima Thank you for investigating! It was extremely helpful! 🙇

So, in my opinion, the root problem is that ActiveModel::Attribute#initialize_dup assumes that attribute values can be copied simply by calling dup:

rails/activemodel/lib/active_model/attribute.rb

Lines 155 to 159 in e741796

	def initialize_dup(other)
	if defined?(@value) && @value.duplicable?
	@value = @value.dup
	end
	end

That can cause surprising behavior in other situations too:

user = User.create!(name: 'Tom')

configuration = user.create_configuration!
configuration.options << Option.create(key: 'key', value: 'secret')

user.update!(cached_configuration: configuration)

user.cached_configuration.options.size     # => 1
user.dup.cached_configuration.options.size # => 0

Or, a more simplified example:

class MyModel
  include ActiveModel::Attributes

  attribute :foo, :immutable_string, default: "foo"
end

m = MyModel.new

m.dup.foo.frozen? # => true
m.foo.frozen?     # => true
m.dup.foo.frozen? # => false

(Though if you are using ActiveModel::Dirty — as ActiveRecord::Base does — its initialize_dup will cover up the issue with frozen strings.)

Unfortunately, fixing ActiveModel::Attribute#initialize_dup is tricky due to cross-cutting concerns. I will continue to think about it, but for now I have submitted #49832 to fix this issue specifically.