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.

Sign up for GitHub

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

Jump to bottom

Under certain conditions, the root cause of a BundledRequestException is never logged #2535

Closed
lmsurpre opened this issue Jun 21, 2021 · 1 comment
Closed

Under certain conditions, the root cause of a BundledRequestException is never logged #2535

lmsurpre opened this issue Jun 21, 2021 · 1 comment
Assignees
@lmsurpre
Labels
bug Something isn't working P1 Priority 1 - Must Have
Milestone
Sprint 2021-09

Comments

@lmsurpre
Copy link
Member

Describe the bug
In FHIRRestHelper.processEntriesByMethod we catch FHIROperationException and, if the request was a transaction bundle (i.e. failFast=true) we construct a generic FHIRRestBundledRequestException with a message of "Error while processing request bundle." and a set of issues from the original FHIROperationException.

This works well if the original FHIROperationException has high-quality OperationOutcomeIssue entries.
However, if the FHIROperationException does not, it results in swallowing the actual root cause.

Environment
4.8.3

To Reproduce
Steps to reproduce the behavior:

  1. Submit a transaction bundle that will fail with a FHIROperationException with no issues (not sure how yet)

Note that the exception is logged.

Expected behavior
Exceptions should be explicitly handled or wrapped and re-thrown, never lost.

Additional context
@lmsurpre lmsurpre added bug Something isn't working P1 Priority 1 - Must Have labels Jun 21, 2021
@lmsurpre lmsurpre added this to the Sprint 2021-08 milestone Jun 21, 2021
@lmsurpre lmsurpre self-assigned this Jun 21, 2021
lmsurpre added a commit that referenced this issue Jun 21, 2021
@lmsurpre
issue #2535 - wrap exceptions instead of losing them
25caf43 
In addition to their OperationOutcomeIssues, we now include the original
exception in the CausedBy of the FHIRRestBundledRequestException.

This way, if the FHIROperationException was unexpected and has no
corresponding issues, when it gets mapped to a 500 Server Error we will
automatically log the exception from
FHIRResource.exceptionResponse(FHIROperationException, Status).

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Jun 21, 2021
@lmsurpre
issue #2535 - wrap exceptions instead of losing them
a250314 
In addition to their OperationOutcomeIssues, we now include the original
exception in the CausedBy of the FHIRRestBundledRequestException.

This way, if the FHIROperationException was unexpected and has no
corresponding issues, when it gets mapped to a 500 Server Error we will
automatically log the exception from
FHIRResource.exceptionResponse(FHIROperationException, Status).

Also changed "bundle request" to "bundled request" in
FHIRRestHelper.logBundleRequestCompletedMsg to match the language at the
start of the bundled request and to make it more clear its the
individual bundled entry that completed and not the entire bundle.

Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre added a commit that referenced this issue Jun 22, 2021
@lmsurpre
Merge pull request #2536 from IBM/issue-2528
b969580 
issue #2535 - wrap exceptions instead of losing them
@prb112 prb112 modified the milestones: Sprint 2021-08, Sprint 2021-09 Jun 29, 2021
@lmsurpre
Copy link
Member Author

lmsurpre commented Jul 7, 2021

the code is now in place for the next time we see this

@lmsurpre lmsurpre closed this as completed Jul 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lmsurpre lmsurpre

Labels
bug Something isn't working P1 Priority 1 - Must Have
Projects
None yet
Milestone
Sprint 2021-09
Development

No branches or pull requests
2 participants
@prb112 @lmsurpre