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

Implement suggestion from #58, with test coverage #91

Merged
merged 4 commits into from
Jan 12, 2024

Conversation

pond
Copy link
Member

@pond pond commented Jan 11, 2024

Implement suggestion from #58, with test coverage.

@pond pond added the enhancement New feature or request label Jan 11, 2024
@pond pond marked this pull request as ready for review January 11, 2024 22:22
def scimitar_rescuable_exceptions
[
ActiveRecord::RecordInvalid,
ActiveRecord::RecordNotSaved
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ActiveRecord::RecordNotSaved
ActiveRecord::RecordNotSaved,
ActiveRecord::RecordNotUnique

Copy link
Member Author

@pond pond Jan 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This raises the issue of exceptions that do not leave an 'offending' record with validation errors present. AFAICT, RecordNotUnique is a thin adapter-specific wrapper over the DB constraint error and does not know what attribute to mark as errant in the model, so does not add error details.

ActiveRecord's documentation on its exceptions is actually very poor and in almost every case lacks information on the fields present in an exception instance and whether or not there are any alterations present in a record that had an operation performed which led to an exception being generated. That's partly of course down to the circumstances under which the error is raised (it's the validation phase in #save! which updates the record's errors collection, not the subsequent raised exception) but it's still something you need to know as an exception handler. I was left reading source code and eventually decided to give up, in part because source code isn't a contract of behaviour anyway; only API docs cover that. Any undocumented behaviour upon which Scimitar relied could change in future.

All of this means the error details in the SCIM response might be incorrect, but since it's a wider issue for all handled exceptions, I'm going to handle this more robustly and will push an update to the PR soon.

@pond
Copy link
Member Author

pond commented Jan 12, 2024

@gsar / @bagp1 - Suggestions from @gsar with related adjustments described by comment above implemented; ready for re-review.

@bagp1 bagp1 merged commit 8d43bc9 into main Jan 12, 2024
5 checks passed
@bagp1 bagp1 deleted the feature/better-exception-handling branch January 12, 2024 04:10
pond added a commit that referenced this pull request Jan 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants