GET /profile/notifications writes to the database
Summary
Visiting /profile/notifications
causes Rails to attempt to write to the database. On a Geo secondary, this fails with ERROR: cannot execute INSERT in a read-only transaction
. When the database is readonly for other reasons, this will also fail.
Steps to reproduce
- Sign into a Geo secondary
- Visit /profile/notifications
What is the current bug behavior?
ERROR: cannot execute INSERT in a read-only transaction
What is the expected correct behavior?
The notifications page
Possible fixes
Relevant part of the backtrace:
activerecord (4.2.10) lib/active_record/persistence.rb:250:in `update'
app/models/user.rb:1041:in `global_notification_setting'
app/controllers/profiles/notifications_controller.rb:6:in `show'
So this method in app/models/user.rb
needs to change:
# Lazy load global notification setting
# Initializes User setting with Participating level if setting not persisted
def global_notification_setting
return @global_notification_setting if defined?(@global_notification_setting)
@global_notification_setting = notification_settings.find_or_initialize_by(source: nil)
@global_notification_setting.update_attributes(level: NotificationSetting.levels[DEFAULT_NOTIFICATION_LEVEL]) unless @global_notification_setting.persisted?
@global_notification_setting
end
app/models/notification_setting.rb
already has:
default_value_for :level, NotificationSetting.levels[:global]
Perhaps we can just change this to be:
default_value_for :level, NotificationSetting.levels[User::DEFAULT_NOTIFICATION_LEVEL] # :participating
instead? Or would this have wider implications?
It seems very strange for your user's notification level to start at global
, then jump to participating
if, and only if, you visit this page.
/cc @jramsay to consider scheduling.
Edited by Nick Thomas