Refactor and Finalize Session Tracking (Building on closed unmerged #74)

[rammakablecode]

Description

This PR integrates and corrects the session tracking logic for the 10.0.x branch. It uses the service-layer approach originally proposed in PR #74, while addressing missing schema definitions and environment blockers currently on 10.0.x.

During testing, I identified issues that blocked development and limited the usefulness of the existing schema:

• MySQL tablespace errors (errno: 194) prevented successful migrations in Windows-hosted Docker environments.
• CRLF line endings in shell scripts caused Dev Container startup failures.
• The frontend would have to fetch every session_activity timestamp and compute gaps client-side, which is inefficient and complex.

To resolve these, this PR:

• Fixes the migration sequence to avoid tablespace issues.
• Standardizes shell scripts to LF line endings for Docker compatibility.
• Adds a duration_minutes column to the marking_sessions table, allowing session durations to be calculated and aggregated directly in the backend.

Frontend impact
Persisting duration_minutes enables direct aggregation via the API and removes the need for complex time-delta calculations in the Angular frontend. This change is intended to support(thoth-tech/doubtfire-web#402). By providing this data via the API, we avoid complex time-delta calculations in the Angular frontend, allowing 402 to be refactored to connect directly to this backend logic since the frontend contributions are yet to connect to exisitng backend.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Test A: Migration Sequence
  Executed bundle exec rails db:migrate:redo VERSION=20250922103033.

  Verified:
  marking_sessions table is created successfully
  duration_minutes column exists
  No MySQL tablespace errors occur

• Test B: Session Tracking Logic
  Ran bundle exec ruby -I test test/services/session_tracker_test.rb.
  Result: 2 runs, 13 assertions, 0 failures, 0 errors.
  Ran bundle exec rails test test/api/marking_sessions_api_test.rb
  6 runs, 67 assertions, 0 failures, 0 errors, 0 skips

Confirmed:
15-minute "sticky" session window works
duration_minutes is correctly updated upon activity.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes

[SteveDala]

@rammakablecode please change the base of this pull request to be thoth-tech:10.0.x.

[rammakablecode]

Changed base @SteveDala thank you for that catch!

[JeffySam]

This looks like a solid and well-thought-out improvement .
The move to persist duration_minutes in the backend is a clear win — it simplifies the frontend considerably and avoids unnecessary client-side time calculations. The rationale around supporting doubtfire-lms#402 is clear, and this feels like the right layer to handle that logic.
Nice catch on the environment blockers as well. Fixing the MySQL tablespace migration issue and normalising line endings removes real friction for anyone developing on Windows/Docker, which is often overlooked.
The service-layer approach remains clean, the session “sticky” window logic is well covered by tests, and the migration/test results give confidence this is safe for 10.0.x. Overall, this is a low-risk change with high practical value. I don’t see anything blocking this from being merged.

[Rana7xi]

This looks good to me overall. The session tracking changes are easy to understand, and storing duration_minutes in the backend makes things much simpler instead of handling time calculations on the frontend.

I like the extra check for start_time in update_session_details as it makes the logic safer and clearer. Limiting the update to when the action is assessing also makes sense and avoids unnecessary updates.

The migration and schema changes look straightforward, and the testing notes are reassuring. I don’t see anything blocking here.

[JeffySam]

This looks like a solid and well-thought-out improvement .
The move to persist duration_minutes in the backend is a clear win — it simplifies the frontend considerably and avoids unnecessary client-side time calculations. The rationale around supporting doubtfire-lms#402 is clear, and this feels like the right layer to handle that logic.
Nice catch on the environment blockers as well. Fixing the MySQL tablespace migration issue and normalising line endings removes real friction for anyone developing on Windows/Docker, which is often overlooked.
The service-layer approach remains clean, the session “sticky” window logic is well covered by tests, and the migration/test results give confidence this is safe for 10.0.x. Overall, this is a low-risk change with high practical value. I don’t see anything blocking this from being merged.

[ishika021]

This appears to have a good look overall and seems to be a thoughtful improvement to session tracking as a whole. Centralizing the calculation of end time and duration for sessions within the MarkingSession Model provides a consistent and clear source of truth, while also persisting duration_minutes in order to establish a clean and reliable contract with consumers downstream, such as analytics and reporting.

Additionally, the approach to updating session details when assessing actions is simple to follow and aligns with the already defined aims of “active marking time.” The test updates associated with this change show that the new tracking logic is reflected in the behavior and help verify that the behavior of the newly created logic will remain stable.

It’s worth noting that this work extends the previously unmerged session-tracking changes in a clean manner, while consolidating similar responsibilities into one clear and concise location in the codebase. This consolidation increases maintainability, and makes future modification of session tracking easier to reason about.

From my perspective, the changes are all consistent, implementation works in accordance with the stated intent of the PR, and the overall structure feels thorough and is ready for use. I am satisfied with this as is.

[rammakablecode]

@BrianDangDev could you approve workflow for checks unit tests

[Rana7xi]

This looks good to me overall. The session tracking changes are easy to understand, and storing duration_minutes in the backend makes things much simpler instead of handling time calculations on the frontend.

I like the extra check for start_time in update_session_details as it makes the logic safer and clearer. Limiting the update to when the action is assessing also makes sense and avoids unnecessary updates.

The migration and schema changes look straightforward, and the testing notes are reassuring. I don’t see anything blocking here.

[BrianDangDev]

Hi Rammaka, please share the payload when user create a session and end a session

[rammakablecode]

Hi Rammaka, please share the payload when user create a session and end a session

marking_session start date is based on first 'assessing' activity 12:51 (UTC) [23:51 AEST]

payload for start_date get request

shows 12:51 (GMT) [23:51 AEST] as expected

end date calculated based on the last start date so no request (sticky session) expected end 13:06 (GMT) [00:06]
verified by analytics page

[BrianDangDev]

Approved please open a upstream PR, remember to cross reference with the front end upsteam PR