[mahikakakkad]

Description

Fixes Jae's report: submitting a time log from the Timer took 10-15 seconds, and the timer kept running and didn't clear. The timer was only stopped AFTER the time entry finished saving, so during a slow save it kept ticking and could be logged twice.

Now the timer stops first, then saves. It also logs the server's exact elapsed time, and a tab whose session was already logged in another tab won't log it again.

Related PRS (if any):

• Needs Mahika - 🔥 echo requestId for every timer action [BE] HGNRest#2474 (without it, every time log waits ~5 seconds)
• This PR is based on Mahika - 🔥 : timer auto-reconnect and stop false chimes [FE] #5751, so only the new changes show here.
  Merge order: backend PR first, then Mahika - 🔥 : timer auto-reconnect and stop false chimes [FE] #5751, then this PR.

Main changes explained:

• TimeEntryForm.jsx: stop the timer before saving the time entry, not after.
• TimeEntryForm.jsx: check the server's timer state right before saving and log the server's elapsed time. If that check times out, it still stops and saves normally instead of getting stuck.
• TimeEntryForm.jsx: the log form closes once the save finishes.
• TimeEntryForm.timerStop.test.jsx: tests for all of the above.

How to test:

1. Check out this branch, npm install, npm run start:local, and run the backend PR above
2. Log in, start the timer, and let it run past 1 minute
3. Click "Stop timer and log time", fill in the form, and submit
4. The timer stops right away and the form closes when the save finishes
5. Open two tabs, log the time in tab 1, then try to log in tab 2. Tab 2 doesn't log it again
6. Verify in dark mode

Screenshots or videos of changes:

Note:

The logged time is the server's time at submit, so it includes the time spent filling in the form.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vidiyala99]

Reviewed at b998c3f by reading the code against HGNRest development plus OneCommunityGlobal/HGNRest#2474, and by running the Timer tests. I couldn't test it in the browser tonight because apidev returns 500 on every endpoint, so everything below comes from the code and a unit test.

What works:

• Stopping before saving fixes the main report: the timer can no longer keep running while a slow save is in flight.
• All 9 tests in TimeEntryForm.timerStop.test.jsx pass locally.

Requesting changes:

1. If the save fails, the retry can't log the time, so the session's time is lost. The flow is GET_TIMER, then STOP_TIMER, then save. If the save fails, the form stays open for a retry (as the comment says). But on retry, submitTimeEntry runs GET_TIMER again. The server stopped the timer on the first attempt, so it now answers started: false. The form then shows "This timer session was already stopped or logged elsewhere", closes, and saves nothing. The timer is already stopped with the leftover time, so the worked time is gone.
   I reproduced this with one extra test in TimeEntryForm.timerStop.test.jsx, using a fake server that remembers its state: sendStop sets started = false, the first postTimeEntry rejects, the second resolves. After two Submit clicks, postTimeEntry ran only once and the form closed. The existing "if saving fails after a confirmed stop" test passes because its sendGetTimerAndConfirm mock always returns started: true, so it never hits the second GET_TIMER.
   This only happens once OneCommunityGlobal/HGNRest#2474 is merged, and the merge order puts it first. Without it, GET_TIMER times out, returns null, and the retry goes through after a 5-second wait. One fix: once this tab's own stop is confirmed, store the confirmed elapsed time in a ref and skip the GET_TIMER and stop steps on a retry, so the retry only re-sends the save.

2. This PR and #5778 fix the same bug in conflicting ways. #5778 (Ansh) pauses on submit and sends CLEAR_TIMER after the save. This PR stops first and keeps STOP_TIMER, so the timer keeps the leftover time instead of resetting. git merge-tree shows the two branches conflict in TimeEntryForm.jsx and Timer.jsx. Only one can merge, so please agree on one with Ansh and Jae.

Not blocking:

• The saved hours and minutes now come from the server's elapsed time, which includes the time spent filling in the form (as your note says). The form can show a smaller number than what gets saved, and the user doesn't see the final value before it's saved.
• The stop-confirm timeout drops from 10 s to 5 s. That's fine, but on a slow connection more submits will now fail with "time was NOT logged".
• (From the code, and seen live on #5778.) postTimeEntry catches HTTP errors and returns the status code instead of throwing, so if the save returns a 500, this PR's catch never runs. The timer is already stopped, and the form closes with "Time logged successfully!". I saw exactly this on #5778 with a mocked 500. Checking the returned status before treating the save as done would fix it.