search

ddicorpo / RecruitInc

2018 - 2019 Capstone Project for Team RecruitInc
Other
1 stars 0 forks source link

BUG: Repair Cron Job #178

Open Winterhart opened 5 years ago

Winterhart commented 5 years ago

General Description

Add back the removed line processUser() in the CronJob, test your implementation with port-of-spain or a small town (e.g. blainville)

23jams commented 5 years ago

i dont think thats the issue. The process user was simply moved to a different timer. Since the place it was at before would encounter starvation due to the controller never finishing its job. Currently it is housed in the updateMatchingAlgo method of cronjob, which is set to run every 5 hours.

23jams commented 5 years ago

https://github.com/ddicorpo/RecruitInc/blob/52a37c3585832dd6953cbdc74819490a02c3d007/recruit-inc-back/src/queue/Controller.ts#L94-L105

I think the bug is related to this block of code. Maybe its not being triggered since we never hit a rate limit. A possible solution is to add a counter that will stop the queues pipeline and allow this stuff to run, before turning the pipeline back on.

MewtR commented 5 years ago

The bug is actually due to the following line in Controller.ts inside the convertToCandidate method: const email: string = user.githubUser.email != undefined && user.githubUser.email.length > 2 ? user.github.email : this.hashCode(user.githubUser.login);

You'll notice that if the user has an email (and it's not an empty string). the email variable is set to user.github.email. It should say user.githubUser.email. As of now, any user with an email will not be added to the applicants table and the converToCandidate method will throw and error that says cannot read property email of undefined. The processUsers function is in fact called and users are properly added to the githubUsers table so that's not the issue.

Winterhart commented 5 years ago

We should test is with a small town

MewtR commented 5 years ago

Yeah I tested it already