[Bug]: deleteSession is non-transactional — partial failure orphans questions or leaves sessions undeleted

[hariom888]

Bug Description

deleteSession (backend/controllers/sessionController.js) runs two independent writes with no transaction: Question.deleteMany({ session: session._id }) followed by session.deleteOne(). If the second operation fails or the process is interrupted between the two calls, the two collections are left in an inconsistent state relative to each other.

Steps to Reproduce

1. Create a session with several linked questions.
2. Trigger DELETE /api/sessions/:id.
3. Simulate a failure between the two write operations (e.g. force session.deleteOne() to throw via a validation hook, DB blip, or process kill mid-request).
4. Inspect the Session and Question collections afterward.

Expected Behavior

Either both the session and its linked questions are deleted together, or neither is — the deletion should be atomic so the two collections never disagree.

Actual Behavior

If failure occurs after Question.deleteMany succeeds but before session.deleteOne() commits, the Session document remains but its linked questions are gone, and getSessionById/getMySessions silently populate an empty questions array with no indication data was lost.

Severity

High

Screenshots / Screen Recording

No response

Browser

No response

Operating System

No response

Additional Context

No response

[hariom888]

Technical understanding: two separate collection mutations are performed sequentially with no transactional boundary, so this is not exception-safe — a failure between the two awaits leaves the system in a state that violates the app's implicit invariant that every Session's questions array points to live Question documents.

Affected: backend/controllers/sessionController.js (deleteSession), models/Session.js, models/Question.js.

Proposed fix approach: wrap both operations in a MongoDB session/transaction (mongoose.startSession() + withTransaction) so the Question deletions and Session deletion commit or roll back atomically. If transactions aren't available (standalone Mongo without replica set), consider reordering to delete the parent Session first (or mark it soft-deleted) before cascading to children, so a mid-operation failure leaves an orphaned-but-harmless Question set rather than a phantom Session.

Regression/unit tests: simulate a thrown error from session.deleteOne() after Question.deleteMany succeeds and assert the transaction rolls back the question deletion; verify successful path still deletes both.

Requesting this as a GSSoC'26 assignment.