Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

errors are not raised when update, update_columns, or destroy versions fail to create #1449

Closed
modosc opened this issue Nov 16, 2023 · 2 comments · Fixed by #1450
Closed
Labels

Comments

@modosc
Copy link
Contributor

modosc commented Nov 16, 2023

paper_trail is inconsistent when Version records cannot be created. in some cases (create) an error is raised, in others (update, update_columns, and destroy) 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:

However, when updating, using update_columns, or destroying a versioned record no error is raised if the Version cannot be created:

version = versions_assoc.create(data)

version = @record.class.paper_trail.version_class.create(data)

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:

  1. an opt-in configuration parameter is added to the current major version which causes update and destroy failures to raise an error.
  2. in the next major version bump this becomes the default behavior.

does this seem reasonable? i'm happy to take this on asap.

@modosc modosc changed the title errors are not raised when update or destroy versions fail to create errors are not raised when update, update_columns, or destroy versions fail to create Nov 16, 2023
Copy link

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.

@github-actions github-actions bot added the Stale label Feb 15, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 23, 2024
@modosc
Copy link
Contributor Author

modosc commented Feb 24, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant