ActiveRecord::SubclassNotFound: Invalid single-table inheritance type: X is not a subclass of Noticed::Notification

[t2]

Upgrading our application to use Noticed 2.5 and running into migration issues.

Rails 7.2.2.1
Noticed 2.5.0

Things I have done:

• Moved all notifications to app/notifiers
• Renamed all *Notification to *Notifier
• Updated syntax to new DSL
• Deleted old Notification model and updated the initializer with previous scopes
• Tested that the notifier works when calling directly

Here is an example notifier that is failing to migrate:

# app/notifiers/application_notifier.rb
class ApplicationNotifier < Noticed::Event
  include ActionView::Helpers::TextHelper
end

# app/notifiers/notes/note_updated_notifier.rb
class Notes::NoteUpdatedNotifier < ApplicationNotifier
  include PushNotifier

  notification_methods do
    def push_notification(device_token, recipient)
      note = event.record

      {
        message: {
          token: device_token,
          data: {
            type: self.class.name,
            screen: 'NoteDetails',
            screenId: note.id&.to_s
          },
          notification: {
            title: 'Your note has been updated!',
            body: "#{note.title} has some updates! Tap here to see."
          },
          android: {
            notification: {
              sound: 'default'
            }
          },
          apns: {
            payload: {
              aps: {
                sound: 'default',
                badge: recipient.unread_notifications_count
              }
            }
          }
        }
      }
    end
  end
end

# app/notifiers/concerns/push_notifier.rb
module PushNotifier
  extend ActiveSupport::Concern

  included do
    deliver_by :fcm do |config|
      config.device_tokens = -> { recipient.devices.pluck(:token) }
      config.credentials = Rails.root.join('config/credentials/fcm.json')
      config.json = ->(device_token) { push_notification(device_token, recipient) }
      config.invalid_token = ->(device_token) { Device.where(token: device_token).destroy_all }
    end
  end
end

When running this migration script I get the error in the title.

class Notification < ActiveRecord::Base
  self.inheritance_column = :_type_disabled
end

# Migrate each record to the new tables
Notification.find_each do |notification|
  attributes = notification.attributes.slice('type', 'created_at', 'updated_at').with_indifferent_access
  attributes[:account_id] = notification.account_id
  attributes[:record_id] = notification.record_id
  attributes[:record_type] = notification.record_type
  attributes[:type] = attributes[:type].sub('Notification', 'Notifier')
  attributes[:params] = Noticed::Coder.load(notification.params)
  attributes[:params] = {} if attributes[:params].try(:has_key?, 'noticed_error') # Skip invalid records

  attributes[:notifications_attributes] = [{
    account_id: notification.account_id,
    type: "#{attributes[:type]}::Notification",
    recipient_type: notification.recipient_type,
    recipient_id: notification.recipient_id,
    read_at: notification.read_at,
    seen_at: notification.read_at,
    created_at: notification.created_at,
    updated_at: notification.updated_at
  }]

  Noticed::Event.create!(attributes)
end

ActiveRecord::SubclassNotFound: Invalid single-table inheritance type: Notes::NoteUpdatedNotifier::Notification is not a subclass of Noticed::Notification
from /Users/trent/.asdf/installs/ruby/3.2.5/lib/ruby/gems/3.2.0/gems/activerecord-7.2.2.1/lib/active_record/inheritance.rb:316:in `find_sti_class'

[excid3]

Does it work with 2.4?

[excid3]

Okay, it's likely caused by this recent change then: 0e49323

[excid3]

I'm betting that const_get is finding the temporary Notification class from the migration.

Maybe just renaming that would work?

class TempNotification < ActiveRecord::Base
  self.inheritance_column = :_type_disabled
  self.table_name = :notifications
end

# TempNotification.find_each ...

[t2]

You're right. Just tried that approach with 2.5 and it worked.

[excid3]

Awesome, I'll change those upgrade notes. It's probably safer that way anyways so the model name never clashes.

Thanks for testing that out for me!