-
Notifications
You must be signed in to change notification settings - Fork 157
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
Patch Replaces Can Save Invalid Types #2207
Comments
if a clever user adds objects of the wrong type to the builder (via reflection), we were never catching this and so the data could become corrupted Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
if a clever user adds objects of the wrong type to the builder (via reflection), we were never catching this and so the data could become corrupted Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Previously, which exception you got was dependent on what was wrong with the patch. And prior to the model changes for this same issue, we actually allowed invalid patches to be applied (in the case of adding, inserting, and replacing on a list). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Previously, which exception you got was dependent on what was wrong with the patch. And prior to the model changes for this same issue, we actually allowed invalid patches to be applied (in the case of adding, inserting, and replacing on a list). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Previously, which exception you got was dependent on what was wrong with the patch. And prior to the model changes for this same issue, we actually allowed invalid patches to be applied (in the case of adding, inserting, and replacing on a list). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Previously, which exception you got was dependent on what was wrong with the patch. And prior to the model changes for this same issue, we actually allowed invalid patches to be applied (in the case of adding, inserting, and replacing on a list). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Previously, which exception you got was dependent on what was wrong with the patch. And prior to the model changes for this same issue, we actually allowed invalid patches to be applied (in the case of adding, inserting, and replacing on a list). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Previously, which exception you got was dependent on what was wrong with the patch. And prior to the model changes for this same issue, we actually allowed invalid patches to be applied (in the case of adding, inserting, and replacing on a list). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Previously, which exception you got was dependent on what was wrong with the patch. And prior to the model changes for this same issue, we actually allowed invalid patches to be applied (in the case of adding, inserting, and replacing on a list). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
Previously, which exception you got was dependent on what was wrong with the patch. And prior to the model changes for this same issue, we actually allowed invalid patches to be applied (in the case of adding, inserting, and replacing on a list). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
issue #2207 - consistently throw FHIRPatchException for bad patches
@lmsurpre Attempted the steps to reproduce and it returns with a 500 Internal Server Error with the following response:
Instead of getting some type of 4xx error, is this the expected behavior? |
previously we threw 500 Sever Error, even in cases where we knew it was likely a bad patch. now we favor 400 errors for those, but unexpected errors should still result in 500 errors Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
It now returns a 400 Bad Request Error, which matches the expected behavior.
Closing. |
Describe the bug
When saving with patch, it seems like it can corrupt existing resources, preventing them from being retrieved properly. This seems to be possible by making a request to save an element as a different type than it was previously (EG: save a valueString in the Patient.extension field (type: Extension).
Environment
IBM FHIR Server 4.6.1 via docker image. presumably 4.6.0 as well, but untested
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I would have expected step 2 to fail, returning a 4xx error with some text about a type mismatch.
Additional context
The text was updated successfully, but these errors were encountered: