Shifting Attendance: Empowering Mentors to Mark Absences

The devlog-ist/landing project manages a critical mentorship booking system. Recently, an automated process designed to handle unattended sessions was found to be causing significant issues, leading to incorrect absence markings and severe consequences for mentees without human oversight.

The Symptoms

Our system had an hourly scheduled command, mentorship:process-absences, which was intended to streamline attendance management. However, it began to misfire, automatically marking past bookings with attended=null as absent. This automation triggered immediate warnings and even reprobations for mentees, leading to the cancellation of their future sessions. In one critical instance, two mentees were reprobated, and 26 of their future bookings were automatically cancelled, all without a mentor's explicit decision.

The Investigation

The core of the problem lay in the mentorship:process-absences command. It operated under the assumption that any past session not explicitly marked as attended should default to absent. While this might seem efficient on paper, it failed to account for situations where a mentor simply hadn't yet updated attendance or where there was a misunderstanding, effectively punishing mentees without due process or a mentor's judgment.

The Culprit

The hourly command was designed to scan for sessions where attended was null and automatically update them to absent. This logic, while seemingly robust for unattended sessions, lacked the crucial human element. It didn't differentiate between a genuinely missed session and one where the attendance status was merely pending mentor input. This lack of nuance was the direct cause of the unwarranted reprobations and session cancellations.

The Fix

To rectify this, we implemented a significant change, moving from an automated system to one that empowers mentors with the authority to mark absences. The mentorship:process-absences command was entirely removed from the hourly schedule.

Now, when a mentor interacts with the dashboard and marks a past session as "no-show," a specific handler, such as MentorAbsenceHandler::processAbsence, is explicitly invoked. This ensures that absence warnings and reprobation flows are only triggered as a direct result of a mentor's action. Additionally, we now stamp the attendance_marked_by field with Mentor (which is cleared on reset) to provide clear attribution for attendance decisions.

Here’s a conceptual look at how a mentor's action might trigger the absence processing:

namespace App\Http\Livewire\Components;

use App\Models\MentorshipBooking;
use App\Services\AbsenceProcessorService;
use Livewire\Component;

class MentorDashboard extends Component
{
    public MentorshipBooking $booking;

    public function markNoShow(): void
    {
        // Ensure the booking is in the past and not already marked
        if ($this->booking->end_time->isPast() && is_null($this->booking->attended)) {
            $this->booking->attended = false; // Mark as absent
            $this->booking->attendance_marked_by = 'Mentor';
            $this->booking->save();

            // Trigger the absence handling logic explicitly
            AbsenceProcessorService::processMentorAbsence($this->booking);

            session()->flash('message', 'Booking marked as no-show successfully.');
        } else {
            session()->flash('error', 'Cannot mark this booking as no-show.');
        }
    }
}

The Lesson

This incident highlights a critical lesson in system design: for processes with significant consequences, especially those impacting users directly, human judgment is often irreplaceable. While automation can boost efficiency, it must be carefully balanced with oversight. Delegating the final decision for sensitive actions like marking absences to the responsible party – the mentor – ensures fairness, accuracy, and accountability, preventing unintended negative impacts from rigid automated rules.