e2e tests fail

[witash]

changes to user management have broken the end-to-end tests, so that the user creation request returns 400.
this is caused by validatePassword, the test password is too weak

Also, at the end of the ltfu spec, the encounter which is meant to be created on the fhir server by completing a task is not created, for unknown reasons

[witash]

running locally, I get this error

  ● Steps to follow the Loss To Follow-Up (LTFU) workflow › Should follow the LTFU workflow

    CHT user creation failed: Reason 400

      75 |     contactId = createUserResponse.body.contact.id;
      76 |   } else {
    > 77 |     throw new Error(`CHT user creation failed: Reason ${createUserResponse.status}`);
         |           ^
      78 |   }
      79 | };
      80 |

      at test/ltfu-flow.spec.ts:77:11
      at fulfilled (test/ltfu-flow.spec.ts:5:58)

because either validatePassword failes, or because validateUsername fails because already exists because database is not being removed properly. so not a problem for remote runs in the github workflow.

the next error is

    Expected: 1
    Received: 0

      175 |
      176 |     expect(retrieveFhirDbEncounter.status).toBe(200);
    > 177 |     expect(retrieveFhirDbEncounter.body.total).toBe(1);
          |                                                ^
      178 |   });
      179 | });
      180 |

      at test/ltfu-flow.spec.ts:177:48
      at fulfilled (test/ltfu-flow.spec.ts:5:58)

so the LTFU flow is supposed to create a task on CHT, and when this task is completed outbound push sends an Encounter to the FHIR server.
It looks like the ltfu spec is working up to this last step; in particular the request to complete the task

cht-interoperability/mediator/test/ltfu-flow.spec.ts

Line 168 in 2938b1b

expect(submitChtTaskResponse.status).toBe(201);

returns 201.

is the task not actually completed, cht returns 201 anyway?
is the encounter not created?
created not sent?

then the next error, for remote run in the github workflow, is
https://github.com/medic/cht-interoperability/actions/runs/10788982689/job/29921014029#step:6:169
probably a rate limit that someone has encountered before and has a workaround for

[lorerod]

For the error in the remote run in the GitHub workflow:
https://github.com/medic/cht-interoperability/actions/runs/10788982689/job/29921014029#step:6:169
I can't find DOCKERHUB_TOKEN or DOCKERHUB_USERNAME in the repository actions settings. Maybe I don't have permission. @njuguna-n @witash, can you please help with this?

[lorerod]

or because validateUsername fails because already exists because database is not being removed properly.

@witash I think the database is not removed properly locally because ${COUCHDB_DATA} is a bind mount to a local directory ./srv.
I hope you don't mind I push a commit to fix(#132): change password to pass validation in tests branch.

[lorerod]

Locally I'm unable to reproduce the error in:
expect(retrieveFhirDbEncounter.body.total).toBe(1);

The e2e es passing:

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        11.65 s
Ran all test suites matching /ltfu-flow.spec.ts/i.

[njuguna-n]

@lorerod I also don't have access to actions settings for the repo. You can reach out to @github-owners on Slack if it's still a blocker.

[witash]

@witash I think the database is not removed properly locally because ${COUCHDB_DATA} is a bind mount to a local directory ./srv.

good catch, I was very confused about why the couchdb data was persisting even when the volumes were destroyed.
Instead of deleting it manually in the script (which gives me permissions errors somehow) maybe we just change this to a normal docker volume; e2e tests will delete it by calling docker compose down -v via startup.sh destroy

[witash]

Locally I'm unable to reproduce the error in: expect(retrieveFhirDbEncounter.body.total).toBe(1);

After running it in on a different computer, it now works for me also.

[witash]

for the rate limit issue, looks like a fix could be to switch to ecr

[lorerod]

@witash I implemented retries when starting containers in #133
Do you think that this issue can be closed?

[lorerod]

As the e2e tests are not failing anymore due to rate limit issues, I’m closing this issue. I’ve created a follow-up issue to Switch Docker Compose to Pull Images from ECR.