Skip to content
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

Could not find table 'solid_errors' #73

Open
cannikin opened this issue Jan 8, 2025 · 1 comment
Open

Could not find table 'solid_errors' #73

cannikin opened this issue Jan 8, 2025 · 1 comment

Comments

@cannikin
Copy link

cannikin commented Jan 8, 2025

I can't figure what's going on here, I originally had solid_errors working fine when I had the tables living in my primary database. I'm trying to move them to a separate stand-alone database just like the README prescribes, but everything just blows up: when an error occurs in the app I get a Could not find table 'solid_errors' instead.

The weird thing is that if I start bin/rails console and look at SolidErrors.connects_to it's nil. If, in the console, I run SolidErrors.connects_to = {database: { writing: :errors}} then everything works fine! I can run SolidErrors::Error.count and 0 is returned.

It's as if the config in my environment files are never running, and solid_errors is falling back to the primary database. But if I didn't have the config in development.rb then the README makes it sound like solid_errors won't run at all? But removing the config from config/development.rb has no effect: I still get the same error. The only way to get past it is to remove the gem completely from my Gemfile.

Thanks for any help!

# config/development.rb

config.solid_errors.connects_to = { database: { writing: :errors } }
config.solid_errors.send_emails = false
config.solid_errors.username = Rails.application.config.solid_errors.username
config.solid_errors.password = Rails.application.config.solid_errors.password
# config/database.yml

default: &default
  adapter: sqlite3
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

databases: &databases
  primary:
    <<: *default
    database: storage/<%= Rails.env %>.sqlite3
  errors:
    <<: *default
    database: storage/<%= Rails.env %>_errors.sqlite3
    migrations_paths: db/errors_migrate

development:
  <<: *databases
# db/errors_schema.rb

ActiveRecord::Schema[8.0].define(version: 2024_12_11_202136) do
  create_table "solid_errors", force: :cascade do |t|
    t.text "exception_class", null: false
    t.text "message", null: false
    t.text "severity", null: false
    t.text "source"
    t.datetime "resolved_at"
    t.string "fingerprint", limit: 64, null: false
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.index ["fingerprint"], name: "index_solid_errors_on_fingerprint", unique: true
    t.index ["resolved_at"], name: "index_solid_errors_on_resolved_at"
  end

  create_table "solid_errors_occurrences", force: :cascade do |t|
    t.integer "error_id", null: false
    t.text "backtrace"
    t.json "context"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.index ["error_id"], name: "index_solid_errors_occurrences_on_error_id"
  end

  add_foreign_key "solid_errors_occurrences", "solid_errors", column: "error_id"
end
@cannikin
Copy link
Author

I was able to work around this by configuring the gem manually in an after_initialize block:

config.after_initialize do
  SolidErrors.connects_to = { database: { writing: :errors } }
  SolidErrors.send_emails = false
  SolidErrors.username = Rails.application.credentials.dig(:solid_errors, :username)
  SolidErrors.password = Rails.application.credentials.dig(:solid_errors, :password)
end

However, if I have the gem loaded in the development group I need to put this config in config/environments/development.rb as well or else I get the Could not find table error any time some other error occurs. (The README doesn't mention only including the gem in the production group so I assumed you could include it everywhere but it would only log errors if the above config was present, but that doesn't seem to be the case—it always logs if the gem is present!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant