Validation cardinality error on Extensions

[bgoorden]

Since the update to hapi-fhir-validation 7.4.4 (version 6.3.23 of org.hl7.fhir.validation), I have random errors in my integration tests. Multiple tests randomly fail on incorrect Validation_VAL_Profile_Minimum errors. This always happens on Extensions.

I debugged the issue and found the problem. I'm using the "org.hl7.fhir.common.hapi.validation.validator.VersionSpecificWorkerContextWrapper". This uses a caching with a default of 10s. Whenever the cache has timed out, it will create a new canonical structure definition. This means when the cache times out during the validation of f.e. multiple resources in a Bundle, the "InstanceValidator.checkExtension" function will have a new StructureDefinition object compared to which was used before. This gives issues when "InstanceValidator.checkCardinalities" function tries to get a list of relevent slices by calling "profileUtilities.getSliceList". This function uses an indexOf with the given ElementDefinition to find the same element in the snapshot element list of the structure definition. When a new structure definition is used no element will be found and this will result in a cardinality error.

https://github.com/hapifhir/org.hl7.fhir.core/blob/cde5d86fe008ccb01fc037aea0332ade1bd4f743/org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/conformance/profile/ProfileUtilities.java#L553

The following test will succeed after the first call to getSliceList (using the same element definition object as used in the snapshot as argument), but will fail on the results of the second call to getSliceList (using a newly created element definition as argument)

class ProfileUtilitiesTest {

  @Test
  void getSliceList() {
    ElementDefinition element1 = (ElementDefinition) new ElementDefinition().setPath("Extension").setId("Extension");
    ElementDefinition element2 = (ElementDefinition) new ElementDefinition().setPath("Extension.id").setId("Extension.id");
    ElementDefinition element3 = (ElementDefinition) new ElementDefinition().setPath("Extension.value[x]")
      .setSlicing(new ElementDefinition.ElementDefinitionSlicingComponent().setDescription("slice")).setId("Extension.value[x]");
    ElementDefinition element4 = (ElementDefinition) new ElementDefinition().setPath("Extension.value[x]").setSliceName("valueCodeableConcept").setId("Extension.value[x]:valueCodeableConcept");

    StructureDefinition.StructureDefinitionSnapshotComponent snapshot = new StructureDefinition.StructureDefinitionSnapshotComponent()
      .setElement(List.of(element1, element2, element3, element4));
    StructureDefinition profile = new StructureDefinition().setSnapshot(snapshot);

    // using same element from snapshot in element
    List<ElementDefinition> elements1 = new ProfileUtilities(null, null, null).getSliceList(profile, element3);
    Assertions.assertEquals(1, elements1.size());
    Assertions.assertEquals(element4, elements1.get(0));

    // using different element as in snapshot with same values
    List<ElementDefinition> elements2 = new ProfileUtilities(null, null, null).getSliceList(profile,
      (ElementDefinition) new ElementDefinition().setPath("Extension.value[x]")
        .setSlicing(new ElementDefinition.ElementDefinitionSlicingComponent().setDescription("slice")).setId("Extension.value[x]"));
    Assertions.assertEquals(1, elements2.size());
    Assertions.assertEquals(element4, elements2.get(0));
  }

}

A compare on id to find the right element in the list would solve this issue. A workaround is to increase the cache timeout, so this issue has a much smaller chance to occur. I can make a pull request for this issue if that helps.

[jamesagnew]

After discussion with @grahamegrieve - Proposed fix is for HAPI's internal cache to not expire for structuredefinitions as long as the underlying SD hasn't changed. This shouldn'y be too hard to fix.

[bgoorden]

Thanks for the response. This still gives a chance of a validation that will give wrongful errors when the structure definition is updated, but I dont think this will happen often.

[jamesagnew]

Hi @bgoorden - I'm trying to create a test that replicates this issue prior to fixing it, and so far I'm not having any luck.

Would you mind to look at the test in #6455 and see if you can tell what is different to the way that you're experiencing this?