[re-created]implement local event handling

[imcaizheng]

No description provided.

[maxceem]

Thank you, @imcaizheng. I've merged the PR for ES processor.

1. I guess all the logic with status would work every time we update objects, no matter if status really changed or no. For the resource bookings we've previously fixed it, so automatic update only happenes one time when status really changed from one status to another. Can we keep the same logic here for all the cases?

2. I've tested all the cases, some of them work, but some no:

   • ✅ If cancel Job, then JobCandidate and ResourceBookings got cancelled
   • ❌ If assigned ResourceBooking, then JobCandidated should got selected, see https://monosnap.com/file/4lNjQR0hKjTuQNhMCvJmyDwNO2cKaa and https://monosnap.com/file/8NO1wRL8uLiBaChNWXPOyxVyRUlCof
   • ❌ If assigned 2 RouserceBooking for Job with "numPositions === 2" then job should got assigned see https://monosnap.com/file/qgnW7iZ54ar8cDP59o0OBG0G9jQvHK and https://monosnap.com/file/JSImWkBsMkVPW5UjptB5QQI0mQcuCJ

[imcaizheng]

I guess all the logic with status would work every time we update objects

Actually when a resource booking is updated, the event handler does check if status changed or not.
It was done with two steps:

• inside ResourceBookingService, omit the status property before sending message if status not changed. See https://github.com/topcoder-platform/taas-apis/pull/85/files#diff-17fa5d6d644d99ef5cd8ce54bd0053e815d7ce9994e5e2d54ca7d6694bbde84cR151
• inside the event handler, check whether status is assigned or not before continue processing. See https://github.com/topcoder-platform/taas-apis/pull/85/files#diff-2d027ed64a706e4f7c3149189ada17b13ad0bc0e85b3a13efebda6b34123aaafR84.

You could see when status is not updated the condition payload.status !== 'assigned' would be evaluated to false(that is, undefined !== 'assigned') so it keeps the logic like what we already fixed.

@maxceem You assumption is correct for the job status updating logic. We can fix it like we did mentioned above. Is it fine to do that?

For the test result, it is wired it does not work for you even I validated all the cases before submitted the PR. I will check it again.

[maxceem]

Actually when a resource booking is updated, the event handler does check if status changed or not.
It was done with two steps:

@imcaizheng Ah, I missed this. I would suggest making this logic more clear and universal. Because now it actually couples service with event processor. As a general solution, we can send the original and updated object to the event. So in even handler we can compare if staus has changed.

This way we can implement any logic in the handler, and check if the date changed or any other field if need in the future.

For the test result, it is wired it does not work for you even I validated all the cases before submitted the PR. I will check it again.

If it works for you, I can try to give you exact steps to reproduce it.

[imcaizheng]

@maxceem The commit fix inconsistence by interating all jobs found filtering by projectId should fix the issues. Please check and suggest.

[imcaizheng]

As a general solution, we can send the original and updated object to the event. So in even handler we can compare if staus has changed.

@maxceem The commit enhancement: encapsulate old value to the event payload as well is the implementation.

[maxceem]

@imcaizheng looking at the code it seems that logic is not what is expected. Could you please, have a look.

[maxceem]

@imcaizheng As I've already merged another PR, could you please resolve the merge conflict here?

[imcaizheng]

@maxceem Conflict resolved.

[maxceem]

@imcaizheng just in case, we still have this issue in this PR:

[imcaizheng]

@maxceem Good catch. it is fixed now.

[maxceem]

@imcaizheng works perfectly now.