[$150] Automatic status updates

[maxceem]

1. When we add/update any ResourceBooking we have to check if the corresponding Job has numPositions === length(ResourceBooking with status === "assigned"). And if so, then update the status of the Job to assigned.

2. If we change Job status to cancelled. Then we should change the status of all ResourceBooking and (updated: don't change status for ResourceBookings) JodCandidate related to this job to cancelled.

[maxceem]

Contest https://www.topcoder.com/challenges/30158837 has been created for this ticket.

This is an automated message for maxceem via Topcoder X

[maxceem]

@imcaizheng open for pickup.

[maxceem]

Contest https://www.topcoder.com/challenges/30158837 has been updated - it has been assigned to aaron2017.

This is an automated message for maxceem via Topcoder X

[imcaizheng]

As a quick solution, we could handle the first requirement inside ResourceBookingService and handle the other requirement inside JobService, but I think decoupling these logic from the services could help improve readability and extensibility.

Creating another taas processor like taas-es-processor to accommodate the logic is a good approach but it could be a bit overhead so I would prefer to make use of the Nodejs built-in event feature to implement a low-budget message dispatching solution.

The solution could be broken into two steps:

1. Setup event emitter inside src/common/helper.js

...

const events = require('events')
const eventEmitter = new events.EventEmitter()

...

async function postEvent (topic, payload) {

  ...

  // emit event locally after the message is sent to BUS API
  // the payload contains all the info we need about the data created/updated
  eventEmitter.emit('bus_event_sent', payload)
}

...

module.exports = {
  eventEmitter
}

2. add listeners to handle the messages about resourceBooking being assigned, job being cancelled, etc.
   We could create a new folder like src/eventHandlers and create scripts inside the folder.
   The scripts could ultilize JobService/JobCandidateService/ResourceBookingService to update data across services.

Eventually all the requirements are implemented outside the services. The services remain clear. Moreover, we could migrate the functionality mentioned on #42 to the event handlers as well.

@maxceem Could we implement the requirements like that? How would you think about it?

[maxceem]

Thank you for considering readability @imcaizheng. Decoupling logic is indeed very needed here.

Though there is one kind of edge cases that would be good to avoid. We have to make sure that this logic for automatic status updates is done during the request, not asynchronously after the request. Otherwise, there would be some time when we have inconsistent data. For example, imagine we have a Job and we are creating a new resourceBooking for it:

• POST ResourceBooking { status: 'assigned' }. Imagine that this was the last resource booking needed so we are firing the event to update the Job's status to assigned. If we process this event asynchronously, then we complete request for creating resourcebooking and send the response to the client. While Job status might not be updated yet, as it's asynchronous.
• Now, if we make another request immediately after the previous one which depends on the Job status, then during this second request data would be inconsistent as Job status might not get updated yet. So at this moment we already have all the resourceBookings in the DB, but job status is not yet assigned.

Quick googling tells that this we cannot wait for EventEmitter event to complete https://stackoverflow.com/questions/10053073/nodejs-wait-for-callback-to-finish-on-event-emit.

There is some workaround mentioned in this article, but not sure if this would work for our case https://www.derpturkey.com/event-emitter-to-promise/

@imcaizheng what do you think about such edge cases?

[imcaizheng]

@maxceem Even if we try to update the Job's status during the request, the job status would still be updated asynchronously after request via taas-es-processor. Unfortunately, based on current implementation, doing updating status synchronously does not help resolve the edge case.

IMO, The edge case is unavoidable unless we merge taas-api and taas-es-processor again, and couple the logic for updating status with the main logic of services. We would unlikely do that.

[maxceem]

Yeah, agree on that @imcaizheng.

Ok, let's go with the way you've suggested with EventEmmiter. We would keep an eye on this if this brings any issues in real usage. It would be also nice to add some good debugging logs there, to make it easier to debug what is going on in case of issues.

Also, please, move there the previously implemented logic as well #42.

I would adjust the price for this ticket taking into account efforts for creating a common code apart from the status logic.

[imcaizheng]

@maxceem There is no cancelled status for JobCandidate. Valid status are open, selected, shortlist, rejected. I think rejected is close to what you mean.

EDIT for the first requirement, by default a resource booking is created, its status is sourcing, so I think we don't need to do the check when creating resource booking.