Can no longer validate presence of an association after upgrade to Rails 4.1

[taryneast]

class MyNotification
   belongs_to :my_other_class, :autosave => true
   validates :recipient, presence: true
   delegate :recipient, :recipient=, to: :my_other_class
   before_create :build_my_class_if_missing

   def build_my_class_if_missing
     my_other_class ||= build_my_other_class(message_type: "MyMessageType")
   end
end

describe "creation" do
  subject(:notification) { MyNotification.create!(recipient: user, request: my_request) }

  its(:recipient) { should == user }
  its(:request) { should == the_request }
end

The create! fails with Validation failed: Recipient can't be blank even though I'm clearly passing a recipient.

This worked in Rails 4.0.
I can see nothing in the upgrade notes or the release notes for 4.1 about what changed to make this stop working.

What changed?
Why did it change?
What can I do to make it work again?

[senny]

@taryneast thank you for your report. Can you attach an executable test-case to reproduce the error? You can use this script as a starting point.

[m5rk]

We attempted to reproduce this issue for Rails 4.0.3, but this gist fails:

https://gist.github.com/m5rk/415570a52fb03f5ff041

[taryneast]

cool, thanks guys, I'll have a go at making a new testable set based on your examples. I've got it running in Rails 4.0 - just need to make sure it breaks (the same way) in Rails 4.1

[taryneast]

Ok, here's the gist. It consistently passes on Rails 4.0 and fails on 4.1.
As you can see, a little more complicated than my original example. We're using a concern for a bunch of this stuff... if you directly copy that stuff into the ItemRequestNotification class it all works, but put it back in the included concern and it fails.

https://gist.github.com/taryneast/957d13ec70f65b262e78

[senny]

I pushed a fix (will backport it to 4-1-stable as well). The bug was not related to the validations but to the notification method. With Rails 4.0 it did overwrite the CollectionProxy but with Rails 4.1 it didn't. This was due to a bug in Active Records module inclusion order.

@taryneast thank you for reporting.