You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Investigate and Fix Incorrect Event Check-In Times in VRMS #1872
Event check-ins in VRMS are being displayed at incorrect times, potentially due to an issue in the event processing flow. A comprehensive review of the entire check-in flow is needed to identify the root cause and implement a permanent fix.
Action Items
Latest update - as of August 4, 2025, PROD backend does not appear to be generating events for check in.
Conduct a full review of the event check-in process to determine where the issue originates.
Investigate whether another worker process is contributing to the incorrect timestamps.
Document findings and outline necessary changes to resolve the issue.
Refactor portions of the create recurring events structure into smaller functions where possible, making them more easily testable via unit tests.
Implement the fix based on findings and refactored code.
Test the solution thoroughly, ensuring event check-ins display the correct times.
Validate across different scenarios to confirm stability.
Do some QA and make sure stuff opens at the right time!
Resources/Instructions
Review existing VRMS event processing and worker logic.
Check relevant logs for inconsistencies in check-in timestamps.
Reference internal documentation related to event handling and worker processes.
@kurtmgray here is the new issue I created to track your work on researching / fixing the check in timing bug. Please feel free to revise this issue however makes sense to you. Note that these are mostly stand in action items for the moment based on what I thought could serve as potential next steps.
Dev validation for every 24 hours for the whole week (Images attached are from the final check, i.e., last 24 hrs):
- Cron executed consistently every 30 minutes with no missed cycles
- No container restarts or OOM events observed
- Check-in open/close operations executed via batchUpdate
- Recurring events created via single batched POST
- No duplicate event creation observed
From all the above log checks, the system remained stable and performed as expected across all cycles and ready for production deployment from my side.
Activity
JackHaeg commentedon Mar 18, 2025
@kurtmgray here is the new issue I created to track your work on researching / fixing the check in timing bug. Please feel free to revise this issue however makes sense to you. Note that these are mostly stand in action items for the moment based on what I thought could serve as potential next steps.
JackHaeg commentedon Mar 24, 2025
@kurtmgray will be leaving the team due to a new position. Un-assigning this issue and placing back in the prioritized backlog.
13 remaining items
JackHaeg commentedon Feb 17, 2026
Hi @Ganeshswaminathan1912 FYI - DEV was rebuilt and can be tested for this issue
Ganeshswaminathan1912 commentedon Feb 23, 2026
Dev validation for every 24 hours for the whole week (Images attached are from the final check, i.e., last 24 hrs):
- Cron executed consistently every 30 minutes with no missed cycles

- No container restarts or OOM events observed

- Check-in open/close operations executed via batchUpdate

- Recurring events created via single batched POST

- No duplicate event creation observed

From all the above log checks, the system remained stable and performed as expected across all cycles and ready for production deployment from my side.
pillarijake commentedon Apr 21, 2026
Ganesh submitted PR, need to test run in dev environment to make sure changes work
pillarijake commentedon May 5, 2026
Dependent on 2143 being fixed
refactor: convert checkin workers to TypeScript
fix: refactor checkin workers for testability and timezone safety (ha…
test(backend): add red tests for timezone/DST bugs in checkin workers
fix: refactor checkin workers for testability and timezone safety (ha…
fix: refactor checkin workers for testability and timezone safety (ha…