Closed modosc closed 8 months ago
This issue has been automatically marked as stale due to inactivity. The resources of our volunteers are limited. Bug reports must provide a script that reproduces the bug, using our template. Feature suggestions must include a promise to build the feature yourself. Thank you for all your contributions.
what do i have to do to get human eyes on this? this is a serious actual bug and i created a pr (complete with documentations and tests). is this project dead?
paper_trail
is inconsistent whenVersion
records cannot be created. in some cases (create
) an error is raised, in others (update
,update_columns
, anddestroy
) an error is logged but not raised. this can result in history silently being lost which is certainly unexpected behavior.Currently when creating a new versioned record an error is raised if the
Version
cannot be created - this is because#save!
is used:https://github.com/paper-trail-gem/paper_trail/blob/47dbc2271c7055fde6f0fe7d3c8bf44f62cbef63/lib/paper_trail/record_trail.rb#L62
However, when updating, using
update_columns
, or destroying a versioned record no error is raised if theVersion
cannot be created:https://github.com/paper-trail-gem/paper_trail/blob/47dbc2271c7055fde6f0fe7d3c8bf44f62cbef63/lib/paper_trail/record_trail.rb#L111
https://github.com/paper-trail-gem/paper_trail/blob/47dbc2271c7055fde6f0fe7d3c8bf44f62cbef63/lib/paper_trail/record_trail.rb#L301
https://github.com/paper-trail-gem/paper_trail/blob/47dbc2271c7055fde6f0fe7d3c8bf44f62cbef63/lib/paper_trail/record_trail.rb#L84
proposal
i think the behavior should be consistent - all failures should either raise errors or not. personally i don't see any advantage to not raising an error in these cases - it likely means that
whodunnit
isn't defined which i would expect to be an oversight rather than intentional. i realize this is not backwards compatible so i propose a two step process:update
anddestroy
failures to raise an error.does this seem reasonable? i'm happy to take this on asap.