Fix leave project issue

[maxceem]

Winning submission from challenge 30091748 - Topcoder Project Service - {with additional code refactoring}

fix removing a member from the ES on member leave or remove so it's not shown in the project listing which is tracked in this issue appirio-tech/connect-app#3059

[vikasrohit]

@maxceem Can we add or improve existing unit test to confirm this?

[vikasrohit]

I have merged the PR @maxceem to verify the changes in dev. It would be good if we can unit test this behaviour. Not urgent but good to have.

[maxceem]

@vikasrohit there is one tricky moment to write proper unit tests for this.

The issues here is that ES index syncing hasn't been done properly. And the syncing process not only run by the internal event (asynchronously), but also ES index operation is also asynchronous and calls an external service.

So far we use timeout 500ms for such cases to check how BUS API events are created, but for them, we have only one thing asynchronous - internal app event. The BUS API event is called synchronously. So mostly we are fine with such an approach with a delay and the false failed tests are rare.

We can try to use the same approach with a timeout to wait for ES indexing, but I guess the spread of possible timeouts here would be bigger. So either we would end-up using a bigger timeout and increase the unit test duration or have more false failed tests. This is just my thoughts, more precisely can tell if we give it a try.

[maxceem]

Note, I see testing on CircleIO failed, but I run unit tests locally and they worked. I guess it is false failing and we can re-run deployment.

[vikasrohit]

Agreed for sync vs async nature of the operations to test. There are couple of things about testing the ES operations:

1. if we go with our regular timeout way, we would pointing to the ES cluster from the docker-compose setup which should return faster
2. Or we can directly/synchronously test the methods in src/events/projectMembers/index.js with
   2.a local ES cluster in docker compose setup
   2.b mocked ES Client
   Anyway, I think for now we are good, but we should be thinking in the direction of unit testing our events handlers.