This repository has been archived by the owner on Oct 17, 2019. It is now read-only.
Prevent crashes on extensions that don't have target profiles #44
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.
Something changed upstream recently and the es6 exporter is now being passed slightly different element definitions for the slice root and fields on Extension.extension. This is causing the exporter to crash as it expects every element definition under an Extension to have a target profile, but the slice root isn't going to have a target profile. (see master where the tests are currently failing despite no changes to the test fixture spec here)
This change just checks for whether the field structure is present before trying to read it, so it doesn't crash if the expected field isn't there.
I do think more testing would be good to ensure that extensions are truly handled correctly in all cases, but at minimum this will ensure the generator continues to function as it did previously, and more importantly doesn't crash. The test on PatientEntry.fromFHIR includes a complex extension which is still handled correctly.
Note: this also disables the BloodPressureSliceByNumber test which is suddenly failing. Based on some limited investigation the issue also seems to be upstream since the profile the generator receives here doesn't contain fixed values for the field named as the discriminator.