@sebjacobs I'm not sure whether this is a bug in how people are modelling their domain or whether it's a behaviour that needs to work. In both your example and the original issue's example the models shouldn't have the :dependent option on the belongs_to association. Why would you initiate the delete on the Content::Position model? It seems a contrived example.

Similarly the example in the original issue has an address at the other end of a has many through which gets deleted when the link is deleted - this suggests that the address should be a direct has many to the user.

@rafaelfranca @sgrif wdyt?

Ignoring the names for the moment and taking your associations, then it's straightforward enough to call @position.content.destroy. I think when deleting object graphs like this you need to have clear entry points for deletion - allowing cascading deletes from what is essentially a leaf node is asking for trouble.

Having said that we should definitely do better at handling it - maybe checking somehow when the association is built?

@pixeltrix you are correct the example is rather contrived.

Perhaps the example below demonstrates a more realistic use case.

create_table "courses" do |t|
  t.string   "slug"
end

create_table "steps" do |t|
  t.integer  "course_id"
  t.integer  "position"
  t.string   "content_type"
  t.integer  "content_id"
end

create_table "articles" do |t|
  t.string   "title"
  t.string   "short_description"
end

create_table "video_articles" do |t|
  t.string   "title"
  t.string   "short_description"
  t.integer  "video_id"
end

class Course < ActiveRecord::Base
  has_many :steps
end

class Step < ActiveRecord::Base
  belongs_to :course
  belongs_to :content, polymorphic: true, dependent: :destroy
end

module Content
  has_one :step, as: :content, dependent: :destroy
end

class Article < ActiveRecord::Base
  include Content
end

class VideoArticle < ActiveRecord::Base
  include Content
end

Having said that we should definitely do better at handling it - maybe checking somehow when the association is built?

It might also be worth documenting this issue in the API docs.

Does this problem only exist when both sides use dependent: :destroy, or also when one side uses dependent: :destroy and the other side has a manual destroy before/after hook?

Because I can think of the following example:

class Post < ActiveRecord::Base
  has_many :comments, dependent: :destroy
end

class Comment < ActiveRecord::Base
  belongs_to :post

  after_destroy do
    post.destroy if post.comments.none?
  end
end

(The idea being, you are modelling a message board post+comment, where the post contains the overall thread subject, but the body of a new user-submitted post is saved as the first comment created at same time as the post itself. Then, either the whole post can get deleted, or all the comments can get deleted, and if they do, the parent post should be implicitly deleted as well.

Is there something I can do to help with this issue? With every new Rails version I have to pull the latest workaround from #13609 😫

@egilburg Yes, the problem is not restricted to dependent: :destroy, but actually affects all after_destroy callbacks. (dependent: :destroy implicitly adds an after_destroy callback) Your code is a prime example for this problem, both callbacks will be called forever, unless one side stops calling destroy. (Which is what @sebjacobs code does, by checking if the callback has been called already)

The fact that everbody is talking about dependent: :destroy is a little bit misleading. @sebjacobs actually fixed a circular callback problem, which just often surfaces when using circular dependencies.

So if this problem should be "fixed in the documentation" it should be done both in the callback and the association sections.

@pixeltrix

I think when deleting object graphs like this you need to have clear entry points for deletion

I can understand your point of view but one could argue the same for circular auto-save associations (and their callbacks!), which are perfecly handled by Rails.
In other words: Why should save callbacks have "loop protection" but destroy callbacks not?

Having said that we should definitely do better at handling it - maybe checking somehow when the association is built?

When first investigating this problem I tried to do that, but it didn't work because the problem is not limited to associations: Even if it were possible, it would still not help with manual after_destroy callbacks.

We are currently in the works of upgrading a Rails 3.2 to Rails 4.1. We encountered this issue.
Does anyone know if this has been dealt with in Rails 4.2?

@Bertg Yes, I seem to be having the issue on Rails 4.2.3

This is great, thanks! ✨

i am glad this was fixed. thanks all

Will this fix be applied in rails 4.2 or only in rails 5?

I checked the code. It's only changed in rails 5