🧩 Summary
The deferral modal scopes its round picker to the registration's course link (courseId, from the [>] Course field), but the participant's actual enrolment is the Round link. These two fields are maintained independently in Airtable and can disagree (though they shouldn't!). When they do, the website offers deferral rounds from the wrong course, and dropout.dropoutOrDeferral accepts them without checking, so a participant deferring "to a later date" gets silently moved to a different course.
Bug report from a real incidence of this.
🛝 Steps to reproduce
You can run this query to find users where these fields do mismatch:
SELECT cr.id, cr.email, cr.decision, cr."courseId" AS reg_course, ar."courseId" AS round_course FROM course_registration cr JOIN applications_round ar ON ar.id = cr."roundId" WHERE ar."courseId" IS NOT NULL AND cr."courseId" <> ar."courseId"
I've yet to work out how this can actually occur
✅ Definition of done
It is no longer possible to have mismatching course and round fields
📌 Notes / Designs
No response
🧩 Summary
The deferral modal scopes its round picker to the registration's course link (
courseId, from the[>] Coursefield), but the participant's actual enrolment is theRoundlink. These two fields are maintained independently in Airtable and can disagree (though they shouldn't!). When they do, the website offers deferral rounds from the wrong course, anddropout.dropoutOrDeferralaccepts them without checking, so a participant deferring "to a later date" gets silently moved to a different course.Bug report from a real incidence of this.
🛝 Steps to reproduce
You can run this query to find users where these fields do mismatch:
I've yet to work out how this can actually occur
✅ Definition of done
It is no longer possible to have mismatching course and round fields
📌 Notes / Designs
No response