You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
v3 notification preferences: PUT with email_cadence but no notification_channel raises KeyError (500) #39221
KeyError: 'notification_channel'
in _prepare_update_data
Internal Server Error: /api/notifications/v3/configurations/
With "notification_channel": "email_cadence" added, the same update succeeds (200). The account MFE always sends the channel, so this is only reachable through the API.
Cause:UserNotificationPreferenceUpdateAllSerializer.validate() deliberately lets email_cadence stand in for the channel (it only requires notification_channel when there is no email_cadence), and NotificationPreferencesViewV3._prepare_response_data infers channel = 'email_cadence' in that case. But _prepare_update_data and _log_preference_update_event both read validated_data['notification_channel'] directly, so the request 500s before the update is applied.
Expected: infer email_cadence as the channel in _prepare_update_data and _log_preference_update_event, as _prepare_response_data already does (or, if the channel is meant to be mandatory, require it in the serializer so the client gets a 400 naming the field).
Environment: Tutor main, image of 2026-09-18; code unchanged on master as of 2026-10-13. Found by the Open edX end-to-end test suite.
The update serializer treats a present email cadence as a substitute for the channel, and the success response already fills the channel in as email_cadence in that case.
The view now resolves one channel for the request: it keeps an explicit channel, and treats a body that only supplies a cadence as the email_cadence channel.
Activity
mvanhorn commentedon Oct 16, 2026
The update serializer treats a present email cadence as a substitute for the channel, and the success response already fills the channel in as email_cadence in that case.
The view now resolves one channel for the request: it keeps an explicit channel, and treats a body that only supplies a cadence as the email_cadence channel.
#39241