The Patient chart component is loading forever in local (docker) instance.

Hi all.

I’m running the O3 by using this (openmrs-distro-referenceapplication/docker-compose-distro.yml at 3.x · openmrs/openmrs-distro-referenceapplication · GitHub) docker image. The docker image is running well. But some components like the patient chart are loading forever.

Screenshot -

Console -

Created a ticket -

It’s a huge blocker for 3.x E2E test since the testing tool uses the dockerized environment. @jnsereko Also facing the same issue here.

cc: @jayasanka @ibacher @raff


FWIW, I get exactly the same problem when i try it out.


I’m not that familiar with the new frontend framework to quickly address the issue, but it seems to be caused by fetching wrong files e.g.: http://localhost/openmrs/spa/openmrs-esm-home-app-3.1.1-pre.88/ whereas it should be fetching: http://localhost/openmrs/spa/openmrs-esm-home-app-3.1.1-pre.88/663.openmrs-esm-home-app.js

Interestingly http://localhost/openmrs/spa/importmap.json points to the right file…

@ibacher do you happen to know where to look to fix the issue?

It’s doing the right thing on so I’m guessing some component version is different on o3.

Nevermind… it’s just DevTools that tries to load the non-existing map. It should not affect the app… Let’s dig further…

@raff i do not think it has anything to do with the docker set up. For i get exactly the same issues even when i do not use docker. That is when i manually set up a local server using this: openmrs-distro-referenceapplication/spa-build-config.json at 3.x · openmrs/openmrs-distro-referenceapplication · GitHub

That’s correct. I think there’s some mismatched dependency versions of esm components. I’m following up with @ibacher on Help to unblock issue with Reporting & Reporting REST modules in O3? - #26 by raff to understand a bit more on how things are bundled together.

is there any way i can override the import file and serve my own patient chart just like import-map-overrides as specified in the o3 openmrs documentation

1 Like

i need to make clinical visit test working and i would wish to try it out on my local running o3 instance using docker.

at the same time, i would wish to do some performance testing on patient-chart in the current docker instance

1 Like

hey @dkayiwa @ibacher @raff this widget is still loading forever, we cant execute the;

  1. O3-1405: Fix clinical visit test
  2. O3-1407: Fix vitals and triage test
  3. O3 1404: Fix user settings test

At the same time, i don’t understand the CI that results into updating the nightly docker instance for 3.x. Knowing this, i guess would give me a better picture of what is happening.
Also being able to override the version of patient-chart running. on the docker instance, i guess, might also help me verify that it is actually Patient-chart failing not any other esm app

It’s build from this source as part of this job. “Nightly” is currently a misnomer, as it’s only run on commits to the source.

Locally, you can build the Docker images and change the versions in this file to whatever you want.

It’s absolutely patient-chart that’s failing. Everything on the patient chart is rendered in this React “page”. When we look at the screen, e.g., as shown below:

You’ll see the SideMenu component is loaded (the left menu), but that the spinner is where the PatientChart component should be. Everything in the center of the patient chart screen is rendered into one of 3 extension slots. But, those extension slots are not rendered and, if you look in the main content (CSS selector #single-spa-application:@openmrs/esm-patient-chart-app-page-0 > div > main, you’ll see the only thing there is the loader.

1 Like

hello @dkigen. I failed to solve this issue

I was able to see all this and it is the loader rendered and the state of isLoading doesn’t change.

Alright, progress! Basically building the images with the updated version of the frontend seems to work.


Patient chart is working now in docker. cc @jayasanka @jnsereko

:partying_face: :partying_face:

Thanks, @ibacher @raff @dkayiwa


For now, I can’t get the frontend to build on ARM architecture, so, unfortunately, the nightly version of the frontend image is only available in AMD64. The backend and the gateway both have ARM64 images available, though.


Thanks, @ibacher Now we can see test workflows are passing in GitHub actions. (But some test are failing)

Fixed, see Reference Application - Distribution 3.x - Build 3.x Frontend 187: Job result summary - OpenMRS Bamboo

I couldn’t figure out why the dev step was failing on arm64, but I figured we didn’t need to have this step in arm64 as the result is the same as in amd64.


hey @ibacher @dkayiwa @raff @pasindur2 Basing on the latest pull, docker instance for 03 ain’t working. I get a blank screen. Its like the getway and the backend images don’t start successfully. 502 bad getway -

At the same time, i think the functionality of registering a patient Might be broken. However i am not so sure because i cant even login to check if its working well.

What’s the output from docker-compose ps and docker-compose logs backend?

docker-compose -f docker/docker-compose-refqa-3x.yml ps  
NAME                COMMAND                  SERVICE             STATUS                PORTS
docker-backend-1    "dumb-init /usr/loca…"   backend             running (unhealthy)>8080/tcp
docker-db-1         "docker-entrypoint.s…"   db                  exited (1)            
docker-frontend-1   "/docker-entrypoint.…"   frontend            running (healthy)     80/tcp
docker-gateway-1    "/docker-entrypoint.…"   gateway             running     >80/tcp

Could you try running docker-compose down -v and then restarting the docker-compose process?