failed to validate with reason: uuid: This value exceeds the maximum length of 38 permitted for this field

[mherman22 (herman muhereza)]

Continuation of the comment at Added xml patching and also covered patient resource by mherman22 · Pull Request #476 · openmrs/openmrs-module-fhir2 · GitHub. When i try to do a json merge patch on the patient resource, the request fails with the error "'Patient#7' failed to validate with reason: uuid: This value exceeds the maximum length of 38 permitted for this field.".

I created an integration test to replicate the error and do step overs using breaking points as advised by @ibacher. Here are the logs of the integration test failure → java.lang.AssertionError: Expected: response with HTTP status indicating reque - Pastebin.com.

The BaseOpenmrsObject seems to provide a maximum length (38) for the uuids as can be seen at https://github.com/openmrs/openmrs-core/blob/27b61fbfe3a45deeb836df5bc7195890645027e8/api/src/main/java/org/openmrs/BaseOpenmrsObject.java#L29. And as for the patch request i am trying to make above, after translation by the OpenMRSFhirTranslator, the uuid field seems to be updated with a value of Patient/61b38324-e2fd-4feb-95b7-9e9a2a4400df instead of maintaining the 61b38324-e2fd-4feb-95b7-9e9a2a4400df that it contained before the translation. This is (i believe) the reason why the maximum length of the uuid field is exceeded hence the error.

details in the pics below after doing step overs.

Before translation:

After translation:

All input is highly welcome, /cc: @ibacher @dkayiwa @mogoodrich @dev5 @abertnamanya

[ibacher (Ian Bacher)]

I don’t think the issue is necessarily in the translator because the translator doesn’t do any transformation of the ID field.

As an aside, the fact that translators just work on getId() is a mistake and, in general, it would be better practice for our translators to looked something like this:

if (!patient.hasIdElement() || !patient.getIdElement().hasIdPart()) {
    currentPatient.setUuid(null);
} else {
    currentPatient.setUuid(patient.getIdElement().getIdPart());
}

(This is a pattern we would need to add to basically every translator that calls setUuid()).

However, I think you may have stepped over the line that calls JsonPatchUtils.apply() a little too quickly. In particular, inside that call, we first translate the resource to a JSON document and later parse the modified JSON back into a FHIR resource. I’m guessing the Patient/ part gets added in one of those two steps (this also might help to explain why this didn’t happen with other resource types).

However, I suppose the root cause doesn’t really matter. If we change the translator as I suggested here, I think the issue will go away.

[mherman22 (herman muhereza)]

@ibacher

As an aside, the fact that translators just work on getId() is a mistake and, in general, it would be better practice for our translators to looked something like this:

This is the push i was about to make the patient resource so that we can only get the IdPart and not the entire id

@ibacher

I suppose the root cause doesn’t really matter. If we change the translator as I suggested here, I think the issue will go away

Yeah it goes away

[mherman22 (herman muhereza)]

Working on [FM2-570] toOpenmrsType translators should set uuid to id part of id, not full id - OpenMRS Issues to have this fixed for all resources