In Rails applications, before_destroy callbacks are commonly used to validate whether a record can be safely deleted. However, simply
adding errors to the model does not automatically prevent destruction.
In Rails versions prior to 5.0, returning false from a callback would halt the callback chain and prevent the destruction. However,
this behavior changed in Rails 5.0 for consistency with other callback types.
Starting with Rails 5.0, callbacks must explicitly use throw :abort to halt execution. The return false approach silently
fails, allowing records to be destroyed despite validation errors.
When callbacks add errors but fail to halt execution, the destruction proceeds normally. This creates a misleading situation where the model
appears to have validation errors, but the record is still deleted from the database. This can lead to data integrity issues, orphaned records, and
broken business logic.
What is the potential impact?
Records may be destroyed despite validation failures, leading to data integrity issues and broken business logic. Users may receive error messages
but still see their data deleted, creating confusion and potential data loss.
