unionlabs/union · error
no database set in config, queue commands require the `pg-qu
Error message
no database set in config, queue commands require the `pg-queue` database backend
What it means
All `voyager queue ...` subcommands (enqueue, requeue, etc.) construct a persistent work queue from `VoyagerConfig.queue`, which is a tagged enum (`QueueConfig`: `in-memory` or `pg-queue`). Only `pg-queue` can be opened as a standalone durable queue from the CLI, because an in-memory queue lives only inside a running relayer process and cannot serve out-of-process queue commands. When the config selects `in-memory`, the closure returns this error before any queue operation starts.
Source
Thrown at voyager/src/main.rs:262
.map(|module_config| get_plugin_info(&module_config).map(|p| p.name))
.collect::<Result<Vec<_>, _>>()?;
print_json(&list);
}
},
Command::Queue(cli_msg) => {
let db = || {
Ok(match get_voyager_config()?.voyager.queue {
QueueConfig::PgQueue(cfg) => {
pg_queue::PgQueue::<VoyagerMessage>::new(PgQueueConfig {
// only one connection is needed for the queue commands
min_connections: 1,
max_connections: 1,
..cfg
})
}
QueueConfig::InMemory => {
return Err(anyhow!(
"no database set in config, queue commands \
require the `pg-queue` database backend"
));
}
})
};
match cli_msg {
QueueCmd::Enqueue { op, rest_url } => {
let rest_url = get_rest_url(rest_url);
send_enqueue(&rest_url, op).await?;
}
QueueCmd::Stats => {
let stats = db()?.await?.stats().await?;
print_json(&stats);
}View on GitHub (pinned to 031785bb6d)
Solutions
- Edit the Voyager config TOML and set the queue to the Postgres backend with a reachable database URL: `queue = { type = "pg-queue", database-url = "postgres://user:pass@host:5432/voyager" }`.
- Confirm Postgres is reachable and the database exists (`psql <url> -c 'select 1'`); apply migrations if this is a fresh database.
- If you did not intend to use queue commands, drop them from your command/script — relaying itself works with either backend.
- If you intended a durable setup, re-generate or diff your config against a known-good production config so other required fields stay valid.
Example fix
# before (config.toml)
queue = { type = "in-memory" }
# $ voyager queue enqueue ...
# error: no database set in config, queue commands require the `pg-queue` database backend
# after (config.toml)
queue = { type = "pg-queue", database-url = "postgres://postgres:postgres@localhost:5432/voyager" } Defensive patterns
Strategy: validation
Validate before calling
# fail fast before running queue commands
tomlq -r '.queue.type' "$VOYAGER_CONFIG" | grep -qx 'pg-queue' || {
echo "queue commands require queue.type = pg-queue in $VOYAGER_CONFIG" >&2; exit 2;
} Type guard
fn has_pg_queue(cfg: &VoyagerConfig) -> bool {
matches!(cfg.queue, QueueConfig::PgQueue(_))
} Prevention
- Generate production configs from a template that already sets `queue.type = "pg-queue"` with a database URL.
- Keep Postgres reachable and migrated before invoking queue subcommands.
- Separate test configs (in-memory) from ops configs in CI so queue commands never run against in-memory setups.
- Assert the queue backend in deployment smoke tests.
When it happens
Trigger: Running `voyager queue enqueue <op>` or any other `queue` subcommand while the config's `queue` field is the default `in-memory` variant (or explicitly set to `{ type = "in-memory" }`).
Common situations: Using a minimal/generated default config that does not configure Postgres; running queue admin commands against a config intended only for testing the relayer in-memory; upgrading voyager after the queue config format changed to the tagged enum and the TOML no longer selects `pg-queue`.
Related errors
- config file must be specified
- plugin not found
- unknown IBC spec `{ibc_spec_id}`
- client info not found
- no ucs03 deployment for {chain_id}
AI-assisted analysis of unionlabs/union@031785bb6d (2026-08-16).
Data as JSON: /api/errors/60b7f9bcfb1b64c7.
Report an issue: GitHub.