Repository navigation
Mahika - 🔥 : timer auto-reconnect and stop false chimes [FE] - #5751
Conversation
✅ Deploy Preview for highestgoodnetwork-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
one-community
added
High Priority - Please Review First
vidiyala99
left a comment
vidiyala99
left a comment
There was a problem hiding this comment.
Tested at head 71dc688 on the review box (FE on this branch, dev backend, test account, timer running at about 00:30).
- Stopped the backend for about 45s, then for 80s+ (the old code gave up at about 61s): the timer showed "Reconnecting..." the whole time. It never switched to "Disconnected", no "Timer Paused" modal appeared, and no countdown ran while the connection was down.
- Started the backend again: the timer reconnected by itself with no refresh and resumed at the server's value (00:28:39 after about 2m15s away from 00:30:54), then ticked normally. Repeated with a 25s outage, same result.
Two small things, neither blocking:
- On one of the two recoveries the display showed 00:15:00 for one sample (I sampled every 3s) before jumping to the real value. It looks like the default message is applied when the new socket clears lastJsonMessage. It fixes itself in a moment, but it is the same "looks like time was lost" flash the Reload fix was meant to remove.
- The PR describes a local chime after 3 failed attempts while the timer was running. In both outages (25s and 80s+) no modal appeared. That is the safe direction for the false-chime bug, but it does not match the description.
Not tested: wifi off/on, laptop sleep, the two-tab case, and the Reload button (only shown for a bad token; I only checked the diff, which removes the reset to 15 min). CI is green (SonarCloud and tests).
Approving.
Backend stopped: timer shows Reconnecting..., no Disconnected, no chime
Backend back up: timer reconnected by itself and resumed at the server value, no refresh
#2 needs to be fixed for sure |
iAbhi001
left a comment
iAbhi001
left a comment
There was a problem hiding this comment.
Tested locally at commit 71dc688 on HighestGoodNetworkApp as DevAdmin in dark mode alongside the development backend. Unit tests in Timer.test.jsx passed cleanly. When stopping the backend, the timer immediately switches to "Reconnecting…" with clear contrast, freezing the local count to prevent runaway completions or false chimes. Once the backend was restarted, the timer reconnected automatically on its own and resumed counting down at 00:13:50 from the synchronized server time without requiring a manual page refresh. Background tabs also re-sync cleanly without triggering delayed chimes upon tab focus. Approving.
one-community
changed the title
…nect attempts from wiping timer state A reconnect attempt resets lastJsonMessage to null until a fresh reply arrives, and an unguarded effect read that as "nothing yet, apply defaultMessage" - wiping started/paused back to false on every single retry. This silently defeated the offline-chime threshold (it could never see "was running" by the time enough attempts had passed, so it never fired no matter how long the outage lasted) and flashed the goal/time display to the hardcoded 15-minute default for a moment on every reconnect. Also speeds up the heartbeat-miss detector (was 60s interval / 4 misses, ~4+ minutes) to a few consecutive misses over ~15-20s, since an abruptly killed backend doesn't always deliver a prompt WebSocket close/error to an already-established connection.
The previous commit's pre-commit hook ran raw prettier --write (which doesn't see eslint-disable comments) and moved NOSONAR off the exact line SonarQube flags, silently making the suppression a no-op. A prettier-ignore on the try statement keeps the catch clause's layout - and the inline NOSONAR comment - intact.
fbef0d4
|
AnshShah-18
left a comment
AnshShah-18
left a comment
There was a problem hiding this comment.
Tested the latest version of PR #5751 locally with the development backend. The timer test suite passed 19/19 tests. During manual testing, I stopped the backend while the timer was running and confirmed that the UI switched to “Reconnecting…” and the local countdown stopped. After repeated failed reconnect attempts, the expected offline pause/chime behavior triggered. Once the backend was restarted, the timer reconnected automatically without requiring a page refresh and resumed from the server value. I also did not observe the previous brief 00:15:00 flash during recovery.
Approving.
|
Thank you all, merging! |
Description
Fixes the timer bugs reported this week:
Related PRS (if any):
Follow-up to #5721 (merged). No backend changes in this PR.
Main changes explained:
How to test:
Screenshots or videos of changes:
Note:
None.