Events timing bug causing meeting check-in options to occur at wrong time

[MattPereira]

Overview

Some of the events in the database have peculiar startTime and endTimes that result in users not being able to check-in to their meetings at the proper time. For this issue, we will investigate and attempt to fix this bug.

Action Items

• Understand why only some of the meetings are affected
  • Explore the client/src/components/manageProjects to determine if the components related to creating events or editing meeting times is source of problem
  • Explore the backend/workers folder to determine if bug originates there
• Determine a viable solution for correcting the problem

Meetings with broken check-in ( could be more )

• TUESDAY Hackforla.org Website DEV 7:00pm - 8:00pm
• THURSDAY People Depot All Team 4:00 pm - 5:00 pm
• THURSDAY Hackforla.org Website DEV Office Hours 7:00pm - 8:30pm

Resources

• Worker file that creates events from recurringEvents
• Folder for components related to events

The People Depot project has a "recurringEvent" with a correct "startTime" of 4:00 PM

The People Depot project has an "event" on 3/30 starting at 2:21PM

Also happening with the Tuesday night 7PM HFLA website Hackforla.org Website DEV meeting

[vanessavun]

Availability: weekday afternoons
ETA: May 15, 2023

[vanessavun]

Update: I am still exploring the VRMS code base and learning how to use MongoDB/Compass. I haven't been able to start debugging. My plan is:

• Check if the bug came from the backend (will the check-in times display at the right times?)
• Check if the bug came from the frontend (is it from the reoccurring event code block or displaying the check in time or updating if it's time to check in)
• Notes: when I made an event/reoccurring event through frontend, the times and dates made in database are correct, following UTC.

Availability: after May 15, 2023 in the weekday afternoons
ETA: May 22, 2023

[vanessavun]

- TUESDAY Hackforla.org Website DEV 7:00pm - 8:00pm
Confirmed that it is at the right reoccurring time in the prod DB:

-THURSDAY Hackforla.org Website DEV Office Hours 7:00pm - 8:30pm
The Thursday dev hours are NOT at the right time in the prod DB. It is set for Tuesday at 7PM:

-THURSDAY People Depot All Team 4:00 pm - 5:00 pm
Confirmed that it is at the right reoccurring time in the prod DB:

Based on what I've looked into so far, there might be several bugs that are working together but I haven't pinpointed what those are. The backend seems to be working, creating the right times in the database. I have not checked if it's in the frontend yet - I will need to write tests for the frontend either by Jest/React Testing.

[jbubar]

During the dev meeting today we discussed how it might be a good place to start to test out the update function on the front end

VRMS/client/src/components/manageProjects/editMeetingTimes.js

Line 65 in 949de40

const date = findNextOccuranceOfDay(values.day);

https://github.com/hackforla/VRMS/blob/development/backend/models/recurringEvent.model.js

[vanessavun]

Found that the Onboarding meeting this past week (Tuesday) was missing for check in.

[vanessavun]

After some research, I'm concluding that we are dealing with multiple bugs.

1. Weird times generated for events to check in
   

2. Events not created to check in
   

3. Event made to check int but it did not show up in the drop down menu
   
   Edit: I just realized that the event was made 2.5 hours AFTER it's supposed to happen.

What is the priority in figuring out first? Why were there weird times? Why are events not being created? Why events made after the meeting times? @Spiteless @MicahBear @MattPereira @jbubar

[JackHaeg]

@Spiteless Can you please review this issue and figure out what the next steps are (e.g., make new issues from what was discovered within this issue, close this issue, revise this issue & put it back in prioritized backlog)?

[vanessavun]

Sorry I’ve been MIA (started a new job that takes all my brain power) and haven’t been able to solve the issue.

The last time I worked this with @MicahBear and @plang-psm, we think a possible solution is to change the CORS timing in generating new events because the backend takes a while (VRMS freezes for a minute or so) to go through thousands of events to check which ones to generate that will go live within the next (?) 30 minutes. So even if an event is made for a time that will start at the hour or at the 30 minute mark, it maybe have been missed to be displayed at check in. If we can check the events at midnight and then have a handful of events that will go live that same day, we will have accurate information to display at the time of checking in.

Without changing the timing of the backend to check for new events every 30 minutes, this might continue to create more inaccurate information because of how long the backend takes to check. Another solution is to reduce the number of events for the backend to check/filter.

[JackHaeg]

@vanessavun Thank you for the summary! We will un-assign you from this issue and if later you are able to come back to the team, we'd be happy to have you!

[JackHaeg]

This is for us to demo the problem (PM meeting used to be called "Planning" before we updated today, note all times are in CDT).

[Spiteless]

I did some digging into this today.

As far as I understand it, the app regular event checkin flow is as follows:

1. Admin creates/edits a project
2. Admin creates a recurring event

• Right now the only option is weekly events

3. The service worker runs every 30m, checking to see if the events that are happening TODAY have been created
4. If an instance of a recurring event needs to be generated, it generates it with a timestamp that comes from the recurring event itself
5. During that every 30m cron job, the service worker also checks to see if an event's checkIn window is coming up

• If it is coming up, it sets the event to checkIn Ready via a PATCH requests

Where are the bugs coming from?

Somewhere along the way older events start times started to get out of wack. That's why we see times like 6:17PM etc. I'm not sure where that came along, but the recurringEvent.date timestamp is used to generate the instance of the recurring event, so if that has an odd time window, the event will never have the right checkIn ready window.

What is the solve

We need to refactor the createAndUpdateEvents file to be more testable. This includes

• Keeping all the current functionality
• Breaking the functions into smaller parts
• Updating the function paramenters to be more testable
• Write tests that to ensure that if this breaks in the future we are better equipped to fix it

Is anything about the events system still functioning properly?

Funny thing is, the cron job that opens and closes the events is working fine, its just that the events are having these supremely weird start times. If we can get events to have the correct start and end times again, the current system will go back to being functional.

Other notes etc

I'm going to take this on and get it fixed. It'll probably take another 2-3 weeks. Hopefully.

I'll work on this

[JackHaeg]

@Spiteless Can you please provide an update on this issue as well?

• Progress: "What is the current status of your project? What have you completed and what is left to do?"
• Blockers: "Difficulties or errors encountered."
• Availability: "How much time will you have this week to work on this issue?"
• ETA: "When do you expect this issue to be completed?"
• Pictures or links* (if necessary): "Add any pictures or links that will help illustrate what you are working on."
• remember to add links to the top of the issue if they are going to be needed again.

[JackHaeg]

#1411 is a duplicate of this issue, closing due to duplication.