Failed to immediately transition LSF proposals to their expected statuses at the closure of the LSF 25-1 call.

[bashanlam]

What is the problem and why is it a problem

Upon the closure of the LSF 25-1 call, LSF proposals did not immediately transition to their expected statuses as defined by the workflow. Specifically, all "draft" proposals were supposed to move to the "expired" status, and all "editable submitted" proposals were expected to move to the "submitted locked" status. Below is email from support.

[deepaksftc]

The job to check for call closure and update the status runs at 0th minute of every hour.

Almost for all our calls we give the call end time of format "--:00". It will be saved in database along with timestamp "--:00:00+00". I could find that, when we choose the end date via dragging through the clock icon/UI, it always (when ever I tested in local) adds 59 seconds extra to the timestamp ("--:00:59+00"). because of some time zone difference.

This has also happened again for HPL call. The call was supposed to end at 12:00, but the job ran at 13.00. Because of the extra seconds added, this call closure was not considered during 12.00 run.

I am not sure if there is way to fix it. 1. One of the possible solution is to manually type the time while choosing the call end time to completely avoid the possibility of having extra seconds.

2. Otherwise, we can make the job run at 1st minute of every hour, which is not a correct way I guess.
3. Else, we can have some hardcoding in code to set the seconds to zero, but that would also need ESS/ELI consent too may be.

Also, there is a possibility of getting it fixed with the overall React and Material UI upgrade (https://github.com/UserOfficeProject/user-office-core/pull/653)

@simonfernandes , @mutambaraf any thoughts?

[simonfernandes]

Just to confirm then, are we saying that when the call closes at 12:00:59, the proposals will remain in EDITABLE_SUBMITTED state until the workflow runs at 13:00:00? From what I remember, we directly check the call end date when editing a proposal and so users wouldn't be able to edit the proposal even if it shows as editable. And it sounds like it's just causing the User Office some confusion and panic for an hour before it resolves itself?

Since the time picker only gives the option to select hours and minutes (I think?) I wouldn't personally see a problem with setting the seconds and milliseconds to always be 0. Though it sounds like we'd still then run into timing issues if the call and job are executing at the same time. That seems a bit unavoidable and why the job runs repeatedly? Maybe we could make the cron format of the job configurable by facility, and then set it to the 1st minute like you suggested (since all of our calls typically end on the hour), or make it more frequent?

[deepaksftc]

Just to confirm then, are we saying that when the call closes at 12:00:59, the proposals will remain in EDITABLE_SUBMITTED state until the workflow runs at 13:00:00? From what I remember, we directly check the call end date when editing a proposal and so users wouldn't be able to edit the proposal even if it shows as editable. And it sounds like it's just causing the User Office some confusion and panic for an hour before it resolves itself?

Since the time picker only gives the option to select hours and minutes (I think?) I wouldn't personally see a problem with setting the seconds and milliseconds to always be 0. Though it sounds like we'd still then run into timing issues if the call and job are executing at the same time. That seems a bit unavoidable and why the job runs repeatedly? Maybe we could make the cron format of the job configurable by facility, and then set it to the 1st minute like you suggested (since all of our calls typically end on the hour), or make it more frequent?

@simonfernandes yes, you are right about the cause of the issue. And yes, setting the seconds and milliseconds to zero, either before inserting to db or while doing the comparison during the job would be the easiest fix. I think, we will not then have any other timing issue, as it will all be covered in date comparison right.