-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data seeding fails if done too quickly #6553
Comments
The issue still exits at release 1.4.1 when trying to setup for local development. With the failure to create user in non Ubuntu based systems. |
@rukshn thank you very much for reporting. I have a hunch the current retry mechanism isn't enough for all environments. I'm guessing you are seeing
|
@rikukissa I looked into the error message, the error seems to be caused by issue in creating a use, there is the stack-trace of the error message
For some reason the data-seeder is unable to create the users, |
Further looking into the error, it seems like the error is originating from the The fetch request that triggers the create user fails with a status code of 500, but no further information is returned from the user management endpoint The below code const res = await fetch(`${USER_MANAGEMENT_URL}${action}User`, {
method: 'POST',
body: JSON.stringify(userPayload),
headers: {
'Content-Type': 'application/json',
...authHeader
}
}
) Generates the following output {
"statusCode": 500,
"error": "Internal Server Error",
"message": "An internal server error occurred"
} |
Thanks! If my memory serves me right, the problem is the user management service trying to store users' details as FHIR too quickly after data reset. When this happens, OpenHIM (our internal service router) is still waking up and not yet able to receive connections causing the failure. The right way of fixing this would of course be waiting for some kind of a ready signal from OpenHIM but as it's a bit of a corner case and only relevant in the local development workflow, we opted to a quick fix implementing a retry mechanism to the seed script. Obviously the 5 retries that we have configured was not enough. Maybe it should continue retrying indefinitely instead @tahmidrahman-dsi |
Before posting the comments, following some of the steps in increasing the retry mechanism to 10, I've actually increased it to 50 retries, and increased the retry time to 10 seconds, instead 5 seconds. And still it didn't get it to work. So I don';t think it's a good solution, I will check the OpenHIM logs what's the output. |
Okay, thanks for testing it. And just to make sure we're on the same page, you first run Let me know if there's anything in the logs. The output of Adding a |
@rikukissa Yes I first ran I don't know where the however it's originating from the user management endpoint running at port |
Thanks @rukshn for the testing, it appears the retry approach did not work for you and it may not also cover all the edge cases, I will work out a more reliable solution (possibly involving verifying if OpenHIM is ready by calling an API endpoint before running seed-script). By the way, did you get a chance trace out the error that originated in the user-mgnt service?
|
@tahmidrahman-dsi Unfortunately I wasn't able to trace the where the error is coming from, as it only throws a very non specific errors. I can confirm that this only fails when you try to develop the system in a non Ubuntu environment, for Ubuntu the setup script works as intended. But not when you are trying to develop in a non Ubuntu environment and triggers this error |
@tahmidrahman-dsi What is the service / package running behind the user management endpoint? I can't seem to find the package or service running behind this service. |
@rukshn Riku and I already shared the path previously. You can actually put a log in here and see the root cause behind the user-mgnt service |
@tahmidrahman-dsi I see that you are working on a fix and a PR is awaiting, I will try again once the PR is merged to see if it is working on a non Ubuntu based systems, |
@tahmidrahman-dsi @rukshn I'm closing this issue now as we have been unable to reproduce the issue. It's highly likely it's something other than a timing issue @rukshn 's case. If the problem persists, it's best to schedule a call with us. In this case, please email us at team@opencrvs.org and please answer the following questions: Please tell us your full name and how you wish to be referred to. |
Describe the bug
A clear and concise description of what the bug is.
Which feature of OpenCRVS your bug concern?
Data seeding in development environment
To Reproduce
Steps to reproduce the behaviour:
yarn seed:dev
right afterExpected behaviour
Environment should seed successfully.
Actual behaviour
There's another bug here as well: if you run the command again, you'll see the script fail already in
This is because the seed script now tries to send an empty array of locations for seeding.
OpenCRVS Core Version:
1.4.0, 1.3.2 (Git branch: master)
Country Configuration Version:
1.4.0, 1.3.2 (Git branch: master)
Tech tasks
The text was updated successfully, but these errors were encountered: