NoMethodError: undefined method 'scan' for nil when dumping schema with Rails 8.0.2 + Ruby 3.4.5

[denizcay]

When using torque-postgresql with Rails 8.0.2 and Ruby 3.4.5, rake db:schema:dump does not work correctly. It fails for table ('products') that include Postgres-specific types or triggers. As a result, none of the triggers defined in the project appear in the generated schema.rb.

Instead of dumping the schema, I get:

# Could not dump table "public.products" because of following NoMethodError
# undefined method `scan` for nil:NilClass

Without the gem, the schema dump works as expected: the table is included and all triggers are present.

1. Rails app with:

   • Ruby 3.4.5
   • Rails 8.0.2
   • Postgres 14.18
   • gem 'torque-postgresql', '~> 4.0'

2. Add a table that contains:

   • jsonb columns with default '{}'::jsonb
   • array columns (character varying[], integer[]) with default '{}'::...[]
   • a tsvector column
   • triggers on the table

3. Run:

   rails db:migrate
   rails db:schema:dump
   

Removing the gem makes the schema dump succeed (table + triggers appear).
I think using config.active_record.schema_format = :sql is a workaround, but I would prefer to keep schema.rb.

Any help or guidance on fixing this issue in Rails 8 would be greatly appreciated.
Thanks in advance for your support and for maintaining this gem!

[crashtech]

Quick question, are you using Versioned Commands to manage triggers or any other gem?

[denizcay]

Thanks for the quick response and for looking into this.

Yes, we are using the fx gem to manage database triggers. Project has trigger definitions located in the db/triggers directory, and use the create_trigger helper within migration files.

Please let me know if you need any more information from our side.

[crashtech]

Can you provide the stack trace, please? This scenario is working.
If possible, a SQL dump of the table structure would also be helpful.

[denizcay]

Here’s a concrete example that reproduces the problem.

Example trigger:

CREATE OR REPLACE FUNCTION book_changed() RETURNS trigger AS $$
BEGIN
  IF OLD.name != NEW.name OR OLD.active != NEW.active THEN
      NEW.updated_at := timezone('utc'::text, now());
  END IF;

  RETURN NEW;
END
$$ LANGUAGE plpgsql;

DROP TRIGGER IF EXISTS book_changed ON books;

CREATE TRIGGER book_changed
  BEFORE INSERT OR UPDATE ON books
  FOR EACH ROW
  EXECUTE FUNCTION book_changed();

Example migration:

class CreateBooks < ActiveRecord::Migration[8.0]
  def change
    create_table(:books) do |t|
      t.string('name',   default: '', null: false)
      t.jsonb('body', default: {}, null: false)
      t.boolean('active', default: true, null: false)
      t.integer('user_id', null: false)
      t.tsvector('tsv')
      t.timestamps
    end

    add_foreign_key(:books, :users, column: :user_id)

    reversible do |dir|
      dir.up   { create_trigger(:book_changed) }
      dir.down { drop_trigger(:book_changed) }
    end
  end
end

Observed behavior

• When this migration runs with torque-postgresql, the generated schema.rb shows:

# Could not dump table "public.books" because of following NoMethodError
#   undefined method 'scan' for nil

• Triggers and functions are not dumped at all in the schema.

• In the test environment, the books table is not exist in schema.rb file and is not created, and migrations that depend on it fail. For example:

ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "books" does not exist

on this line:

add_foreign_key(:books, :users, column: :user_id)

Removing the torque gem completely makes everything work as expected:

• schema.rb includes the table and trigger definitions,
• migrations run successfully in the test environment.

If I remove the tsvector column (remove_column(:books, :tsv)) when torque gem installed, the books table does appear in the schema, but triggers are still missing.

Notes

This behavior started after upgrading to Rails 8.0.2 and torque 4.0
With earlier versions, the same setup worked fine.
The issue might be specifically related to how torque handles the tsvector type.

Thanks in advance for your guidance — happy to share more details if needed.

[crashtech]

This is now fixed on v4.0.1, could you please test? Sorry that it took some time.

[denizcay]

Thank you for the update! I’ll test it on v4.0.1. Much appreciated.