Bug: Tutor Link Issue After Deletion

by Admin 37 views
Bug: Tutor Link Issue After Deletion

Hey guys, we've got a tricky bug to discuss today! It's about a situation where, after deleting a tutor, they're still showing as linked to the class. This is causing some major headaches, as it's preventing us from linking new tutors or even unlinking the old one. Let's dive into the specifics and see what's going on.

The Problem: Ghost Tutors in the System

The core issue is that when a tutor is deleted from the system, the link between that tutor and their assigned class isn't being properly removed. It's like a ghostly connection is lingering, even though the tutor is technically gone. This has some pretty significant consequences:

  • Unable to Link New Tutors: The system seems to think a tutor is already assigned, so it won't allow a new tutor to be linked to the class. This is a major roadblock for scheduling and resource allocation.
  • Unable to Unlink the Old Tutor: Even though the tutor has been deleted, the option to unlink them from the class is also broken. It's like the system is stuck in a state of limbo.

This problem was reported in the AY2526S1-CS2103T-T11-4 class, specifically. A user tried to link a new tutor, Sharon, to the class after the original tutor was deleted, but the system wouldn't allow it. This is a clear sign that the linking mechanism is not functioning correctly after a tutor deletion.

Understanding the Technical Details

To really get a handle on this bug, we need to understand what's happening behind the scenes. Here's a breakdown of the key areas we should be investigating:

  • Database Relationships: How are tutors and classes linked in the database? Is there a foreign key relationship that's not being updated correctly when a tutor is deleted? Are there any orphaned records?
  • Deletion Logic: What's the process for deleting a tutor? Is it a hard delete (removing the tutor record entirely) or a soft delete (marking the tutor as inactive)? If it's a soft delete, is the linking logic taking this into account?
  • Linking/Unlinking Logic: How does the system handle the process of linking and unlinking tutors from classes? Is there any validation logic that might be causing the issue? Is there a race condition in the code?
  • Caching: Is there any caching mechanism in place that might be holding onto old data? If so, how is the cache being invalidated when a tutor is deleted?

By digging into these areas, we can start to pinpoint the exact cause of the bug and develop a fix.

Steps to Reproduce the Bug

To effectively tackle this bug, we need to be able to reliably reproduce it. This will allow us to test our fixes and make sure the problem is truly resolved. Here's a step-by-step guide on how to reproduce the issue:

  1. Identify a Class: Choose a class that currently has a tutor assigned to it. Note down the class ID and the tutor's name.
  2. Delete the Tutor: Go through the process of deleting the assigned tutor. Make sure to follow the standard deletion procedure.
  3. Attempt to Link a New Tutor: Try to link a different tutor to the same class. This is where the bug should manifest itself – the system should prevent you from linking a new tutor.
  4. Attempt to Unlink the Old Tutor: Try to unlink the original tutor from the class. You should also find that this action is blocked.

By following these steps, we can consistently reproduce the bug and verify our solutions.

Potential Causes and Solutions

Based on the information we have, here are some potential causes of the bug and how we might address them:

  • Database Issue: The database link between the tutor and class might not be deleted upon tutor deletion. This could be due to a missing cascade delete or an error in the deletion logic. Solution: Implement a cascade delete or ensure the deletion logic correctly removes the link in the database.
  • Caching Problem: The system might be caching the old tutor-class link, preventing updates. Solution: Implement a cache invalidation mechanism that clears the cache when a tutor is deleted.
  • Logic Error: There could be a flaw in the code that handles tutor linking and unlinking, causing the system to incorrectly maintain the old link. Solution: Review the linking and unlinking logic, identifying and correcting any errors.

It's crucial that we look at all potential causes to ensure we implement the best solution.

Proposed Solutions and Implementation

Okay, guys, let's talk about how we can fix this! Based on the possible causes, here are some solutions we can try:

  • Database Cascade Delete: The first thing we should check is the database schema. We need to make sure that there's a cascade delete set up between the tutors and classes tables. This means that when a tutor is deleted, any associated records in the classes table (or any other related tables) are automatically deleted as well. This will prevent those pesky orphaned records from hanging around and causing problems. To implement this, we'll need to modify the database schema and potentially run a migration to update the existing database.
  • Cache Invalidation: If we're using any caching mechanisms (like Redis or Memcached), we need to make sure that the cache is being properly invalidated when a tutor is deleted. This means that whenever a tutor is deleted, we need to explicitly remove any cached data related to that tutor and their class assignments. This will ensure that the system always has the most up-to-date information. To implement this, we'll need to add code to the tutor deletion process that clears the relevant cache entries.
  • Code Review of Linking/Unlinking Logic: We need to do a deep dive into the code that handles tutor linking and unlinking. This means carefully reviewing the code, looking for any potential errors or edge cases that might be causing the issue. We should pay special attention to the logic that checks for existing tutor assignments and the logic that updates the database. To implement this, we'll need to set aside some time for code review and potentially pair programming to get a fresh perspective on the code.

For implementation, we should start with the database cascade delete, as this is a common cause of these types of issues. We can then move on to cache invalidation and code review if the problem persists.

Testing and Verification

Alright, so we've got some potential fixes in mind. But before we roll anything out, we need to make sure it actually works! That's where testing comes in. Here's our plan for testing and verifying the solution:

  1. Unit Tests: We'll start by writing unit tests for the specific code that we've changed. This will help us ensure that the individual components are working correctly. For example, we'll write tests to verify that the database cascade delete is working as expected and that the cache is being properly invalidated.
  2. Integration Tests: Next, we'll write integration tests to verify that the different parts of the system are working together correctly. This will help us catch any issues that might arise when the components are integrated. For example, we'll write tests to verify that we can successfully delete a tutor and then link a new tutor to the class.
  3. Manual Testing: Finally, we'll do some manual testing to make sure that the bug is truly fixed and that there are no other unexpected side effects. This will involve manually reproducing the steps to trigger the bug and verifying that it no longer occurs. We'll also do some exploratory testing to see if we can find any other related issues.

We'll document our testing process and results to make sure that we have a clear record of what we've tested and what the results were.

Conclusion

So, guys, this