Include more information in RecordNotFound errors. #214
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
What do people think of a change like this? Putting it up as a RFC / WIP. |
|
I was about to open an issue on this topic, having some way to identify or modify this behavior would be really nice. Including additional information in the error payload seems like a good first step in improving how the client can handle this. I'm also curious whether there is some way to handle this scenario without throwing, and instead allowing model validation errors to deliver the message. |
|
I agree this is great, thanks @jackcasey ! If you can please make the standardrb check pass I will happily merge. To @aribouius there may be additional improvements we can make, but let's tackle them in a separate issue |
|
@richmolj yep totally agree 👍 |
jackcasey
force-pushed
the
feature/better_relationship_errors
branch
2 times, most recently
from
f9e799e to
8853937
Compare
When supplying a relationship to an existing resource, if the record cannot be found then supply the resource name, id and relative json path in the Graphiti::Errors::NotFound exception raised.
jackcasey
force-pushed
the
feature/better_relationship_errors
branch
from
8853937 to
b8f40ed
Compare
|
Thanks so much @jackcasey ❤️ ! |
richmolj
pushed a commit
to richmolj/graphiti
that referenced
this pull request
Jan 30, 2021
[This issue](graphiti-api/graphiti-rails#65) raised the idea that we should be treating a missing sideposted record as a validation, not a 401. In the course of this work I found [this older PR](graphiti-api#214), which initially raised the same point iin [this comment](graphiti-api#214 (comment)). I very much agree that this should be a validation error, not a 401, but it breaks backwards compatibility. So, you can opt-in to this behavior with `Graphiti.config.raise_on_missing_sidepost = false`. We should consider this a best practice going forward and note it in the blog.
richmolj
pushed a commit
to richmolj/graphiti
that referenced
this pull request
Feb 1, 2021
[This issue](graphiti-api/graphiti-rails#65) raised the idea that we should be treating a missing sideposted record as a validation, not a 401. In the course of this work I found [this older PR](graphiti-api#214), which initially raised the same point iin [this comment](graphiti-api#214 (comment)). I very much agree that this should be a validation error, not a 401, but it breaks backwards compatibility. So, you can opt-in to this behavior with `Graphiti.config.raise_on_missing_sidepost = false`. We should consider this a best practice going forward and note it in the blog.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When supplying a relationship to an existing resource, if the record cannot
be found then supply the resource name, id and relative json path in the
Graphiti::Errors::NotFoundexception raised.