-
-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New notifications params
are suddenly encoded as string in postgres
#291
Comments
Hi. We recently came across the same issue described above. For us it looks like it's caused by: Lines 47 to 51 in c4b364e
We upgraded our db recently and this caused the above warning to be logged. Our The problem fixes itself I guess when the class is re-loaded (ie on deploy) but the existing A simple and possibly naive fix for this would be to run: Notification.find_each.select { |no| no.params.is_a?(String) }.each do |no|
no.update!(params: ActiveJob::Arguments.send(:deserialize_argument, JSON.parse(no.params)))
end |
That makes sense. Maybe caching that value would be a solution here. Either that, or we could specify the coder in a config so it's always set to the same value and won't accidentally change. |
Sounds good or another possibility, slightly hacky perhaps, is overriding include Noticed::Model
serialize :params, Noticed::Coder |
@jpawlyn Thank you for your sharing! I had not known about class Notification < ApplicationRecord
include Noticed::Model
belongs_to :recipient, polymorphic: true
def params
return self[:params] if self[:params].class == Hash
JSON.parse(self[:params]).transform_keys(&:to_sym)
end
end |
Did anyone resolve this with a long term fix or discover the root cause? |
I've been using
noticed
for a long time without any issue. But after recovering from a full disk space incident of my server (No space left on device), I found some users reporting 500 status errors that are related to notification. After investigating, I found some faulty notifications that are causing the problem. An example is this notification ID:After checking that notification ID further, it seems that the
params
of that notification is in text string instead of hash, makes it impossible to callnotification.params[:manga_id]
:Most of the notifications before still rendered correctly:
The
params
column in thenotifications
table hasjsonb
type:Expected: Notification's params can be accessed as hash (
notification.params[:manga_id]
).Actual: Notification's params cannot be accessed as hash
Does anyone have any idea what can cause this? Could this be postgresql's fault?
The text was updated successfully, but these errors were encountered: