In Bed-Management module, to assign a bed, bahmni make an encounter API call(openmrs/ws/rest/v1/bahmnicore/bahmniencounter) followed by
assign bed API call(openmrs/ws/rest/v1/beds/). Suppose for any reason if the second call fails to happen due to flakey network/browser being closed then there is no mechanism to revert the changes made by the first API call which is leaving the system in inconsistent state.
After clicking the admit button, I made the network offline to stop the second API call to assign bed. (In real time scenarios, it can happen by flakey network, user closing the browser etc)
Impact:
In the Bed-Management module, bed is not assigned to patient and i still see admit option to that patient after reloading the page or opening the page again freshly.
But in a few other places in bahmni, I see a bed icon beside the patient to indicate that bed is assigned to the patient which is not expected as the bed is not assigned.
Note:
In general, Bahmni makes multiple API calls sequentially to complete one action. So, similarly there can be similar issues in other features as well, where multiple API calls happen.
Hi @tarunshettygari - is this a scenario you have seen happen in some actual implementation, or something you encountered while doing testing?
I agree that network outages can cause certain UI calls to not go through, and this is quite likely possible in Bahmni’s targeted environments, where network infra can be flaky. Most SPA/Rich-apps nowadays fire multiple backend calls for one user action, but a good design will ensure that the backend system never goes into an inconsistent state, and always has some other UI option for “Reseting” the problem back.
In this particular case of bed-assignment, if you are able to easily reproduce the inconsistent state, then I think logging a JIRA bug would be good, with exact reproduction steps. The solution would be to either club the mutations across a single API call from the UI, or to provide easier ways to undo the impact when detected. Further analysis of the bug will provide clarity on a good solution.
This was identified as part of our QA testing. None of our prod implementations reported this issue as of now. As this is not reported in prod system this is not a priority for us. But just created a placeholder to take community inputs and check if anyone in community is impacted with such issues so far.
