How to access the full server-log of dev3.openmrs.org on each request: Tired of HTTP 400 Bad Request with GET, PUT, DELETE via HAPI-Client

Projects FHIR
, ,
1

I have used the HAPI-FHIR Generic Client to automate FHIR Patient CRUD operations on via the dev3.openmrs.org instance.

Refer to the PR → https://github.com/openmrs/openmrs-module-fhir2/pull/402

When I point to the OpenMRS dev3 instance ie SERVER_BASE = "https://dev3.openmrs.org/openmrs/ws/fhir2/R4" with the Community Outreach location like PATIENT_LOCATION_UUID = "1ce1b7d4-c865-4178-82b0-5932e51503d6",

Only the @BeforeClass -> shouldCreatePatient() runs successfully. The patient is created, and the rest return a small portion of the error which is less informative of the fault and hence not-helping.


Caused by: ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: HTTP 400 Bad Request
        at org.openmrs.module.fhir.patient.PatientDomainTest.lambda$shouldThrow404WithNonExistingPatient$0(PatientDomainTest.java:129)
        at org.openmrs.module.fhir.patient.PatientDomainTest.shouldThrow404WithNonExistingPatient(PatientDomainTest.java:128)

[ERROR] org.openmrs.module.fhir.patient.PatientDomainTest.shouldGetPatientDomainByUUID  Time elapsed: 1.133 s  <<< ERROR!
ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: HTTP 400 Bad Request
        at org.openmrs.module.fhir.patient.PatientDomainTest.shouldGetPatientDomainByUUID(PatientDomainTest.java:115)

[ERROR] org.openmrs.module.fhir.patient.PatientDomainTest.updatePatientByUUID  Time elapsed: 1.135 s  <<< ERROR!
ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: HTTP 400 Bad Request
        at org.openmrs.module.fhir.patient.PatientDomainTest.updatePatientByUUID(PatientDomainTest.java:148)

[ERROR] org.openmrs.module.fhir.patient.PatientDomainTest  Time elapsed: 2.199 s  <<< ERROR!
ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: HTTP 400 Bad Request
        at org.openmrs.module.fhir.patient.PatientDomainTest.shouldDeletePatientByUUID(PatientDomainTest.java:162)

However, when I run this locally using the SDK watching the latest changes of openmrs-module-fhir2 with SERVER_BASE = "http://localhost:8090/openmrs/ws/fhir2/R4" and Isolation Ward location as PATIENT_LOCATION_UUID = "2131aff8-2e2a-480a-b7ab-4ac53250262b". It works pretty fine.

Screenshot 2022-05-19 at 21 13 24

Question

cc @ibacher @mozzy @dkayiwa @mseaton @mogoodrich @kdaud @sharif

2

Are your changes publicly available for anyone to locally reproduce the problem?

1 Like
3

@dkayiwa the above is the PR i created

4

there might be need to also change the identifier because "1000H0E" might have been assigned already when the tests executed via github-actions

so you might also need to alter PATIENT_IDENTIFIER_ID = "1000H45" generated with

POST /openmrs/ws/rest/v1/idgen/identifiersource/8549f706-7e85-4c1d-9424-217d50a2988b/identifier HTTP/1.1
Host: dev3.openmrs.org
Content-Type: application/json
Authorization: Basic YWRtaW46QWRtaW4xMjM=
Cache-Control: no-cache
Postman-Token: bbfeb383-f3d2-5fb4-628d-4ac9e05ebcc4

{
	"comment": "created for the new FHIR patient Rest-API test"
}

thank you @dkayiwa for the response

5

If you catch the exception, you should be able to get a somewhat more informative message via the OperationOutcome. However: an HTTP 400 response indicates that the client sent a request that the server does not understand.

At a quick thought: at the start of each method, you call authenticate(). Your authenticate() method then registers an interceptor that adds a basic auth header. Because nothing is done to clear those, it seems like you are probably sending a request that looks something like this:

...
Authorization: Basic 1234
Authorization: Basic 1234
Authorization: Basic 1234
...

Because there are a few different layers in line when talking to dev3 (roughly two nginx servers) its likely that one of them is rejecting the request. Can you please refactor things so that authenticate() is only called once? (You can just make it a @BeforeClass method, since that’s when everything is being setup).

2 Likes
6

Thank you @ibacher This was really hard for me to hunt down.