Could not find table 'solid_queue_recurring_tasks'

My Rails 8.0.1 app cannot deploy and its raise the error bellow ( I have tried to destroy the app then launch again but doesn’t work) , I use solidqueue with sqlite.
I tried in docker local its works without any error

 /usr/local/bundle/ruby/3.3.0/gems/activerecord-8.0.1/lib/active_record/connection_adapters/sqlite3_adapter.rb:512:in `table_structure': Could not find table 'solid_queue_recurring_tasks' (ActiveRecord::StatementInvalid)

My fly.toml

# fly.toml app configuration file generated for thirteenproject on 2025-01-26T12:15:22+07:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#

app = 'thirteenproject'
primary_region = 'sin'
console_command = '/rails/bin/rails console'

[build]

[env]
  DATABASE_URL = 'sqlite3:///data/production.sqlite3'

[processes]
  web = 'bin/rails server -b [::] -p 3000'
  worker = 'bin/jobs'

[[mounts]]
  source = 'data'
  destination = '/data'

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 0
  processes = ['web']

  [[http_service.checks]]
    interval = '10s'
    timeout = '2s'
    grace_period = '5s'
    method = 'GET'
    path = '/up'
    protocol = 'http'
    tls_skip_verify = false

    [http_service.checks.headers]
      X-Forwarded-Proto = 'https'

[checks]
  [checks.status]
    port = 3000
    type = 'http'
    interval = '10s'
    timeout = '2s'
    grace_period = '5s'
    method = 'GET'
    path = '/up'
    protocol = 'http'
    tls_skip_verify = false

    [checks.status.headers]
      X-Forwarded-Proto = 'https'

[[vm]]
  memory = '1gb'
  cpu_kind = 'shared'
  cpus = 1

[[statics]]
  guest_path = '/rails/public'
  url_prefix = '/'

database.yml

# SQLite. Versions 3.8.0 and up are supported.
#   gem install sqlite3
#
#   Ensure the SQLite 3 gem is defined in your Gemfile
#   gem "sqlite3"
#
default: &default
  adapter: sqlite3
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

development:
  <<: *default
  database: storage/development.sqlite3

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  <<: *default
  database: storage/test.sqlite3


# Store production database in the storage/ directory, which by default
# is mounted as a persistent Docker volume in config/deploy.yml.
production:
  primary:
    <<: *default
    database: storage/production.sqlite3
    url: <%= ENV["DATABASE_URL"] %>
  cache:
    <<: *default
    database: storage/production_cache.sqlite3
    migrations_paths: db/cache_migrate
    url: <%= URI.parse(ENV["DATABASE_URL"]).tap { |url| url.path += "_cache" } if ENV["DATABASE_URL"] %>
  queue:
    <<: *default
    database: storage/production_queue.sqlite3
    migrations_paths: db/queue_migrate
    url: <%= URI.parse(ENV["DATABASE_URL"]).tap { |url| url.path += "_queue" } if ENV["DATABASE_URL"] %>
  cable:
    <<: *default
    database: storage/production_cable.sqlite3
    migrations_paths: db/cable_migrate
    url: <%= URI.parse(ENV["DATABASE_URL"]).tap { |url| url.path += "_cable" } if ENV["DATABASE_URL"] %>

Hi… Volumes aren’t shared on the Fly.io platform, :cactus:. How many Machines do you have, at the moment?

(You can see this with fly m list.)

1 Like

I use 2 machines and I want them to be in isolated, 1 for background jobs ( so it won’t shutdown ) and 1 for web UI

Typically, the UI and jobs sides need shared access to a common database, so SQLite generally won’t work in this configuration.

(Possibly I’ve incorrectly guessed what you’re doing, though.)

I.e., whatever volume the UI Machine has won’t be accessible from the jobs Machine, and vice versa.


Moreover, having only a single volume and having only a single UI Machine both come with major caveats on the Fly.io platform, although @rubys has been working on mitigating the former.


There was talk back in October about making the SolidQueue+SQLite combination more tenable on Fly.io, but I don’t know how far that’s progressed…

(Also, one user reported getting SolidQueue+LiteFS working, which is a lot of effort, but was a definite achievement that does solve both.)

1 Like

One more thing, my app used to run well 2 months ago, but last week it got a faulty. I cannot start or stop, so I try to destroy the app then launch again and this issue occurred

Let’s start with this: two machines can’t update a shared sqlite3 database. The best you can do with sqlite with multiple machines is to create a read only replica on one, and that is not good enough for solid queue.

So if you want two machines and solid queue, you want postgresql. Or you can go with sqlite and one machine. Reference configurations: postgres and sqlite. If you go with sqlite, I do strongly recommend setting up litestream - reference configuration.

The easiest way to start solid queue on the same machine is to have Puma start it for you:

Now what you are seeing with two machines is that you have two sqlite3 databases. On one (web), db:prepare is run. On the other (worker) it isn’t, so that machine will fail to find table ‘solid_queue_recurring_tasks’

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.