clockworklabs/SpacetimeDB · error

the following required arguments were not provided: <

Error message

the following required arguments were not provided:
  <{}>

Usage: {}

What it means

resolve_optional_database_parts (crates/cli/src/subcommands/db_arg_resolution.rs:91) emits a clap-style usage error when there are no config targets (--no-config passed, or no spacetime.json found) and fewer than two raw positionals remain: an empty invocation reports the missing <database>, while a single positional reports the command-specific required argument (e.g. <function_name> for call, the query for subscribe). Without config, both the database and the command's own argument must be supplied positionally.

Solutions

1. Supply both positionals when using --no-config: `spacetime call <database> <function_name> <args...> --no-config` (same shape for subscribe with its query).
2. Or run from a directory containing a spacetime.json defining the database, so the database part can be omitted.
3. Guard scripts by checking `$#` before invoking so the usage error never reaches the CLI.

Example fix

# before: no config, missing function name
spacetime call mydb --no-config
# after
spacetime call mydb my-reducer '[1,2]' --no-config

# When using --no-config, require at least database + the command's own first arg:
usage() { echo "usage: $(basename "$0") <database> <function_name> [args...]" >&2; exit 2; }
[ "$#" -ge 2 ] || usage
spacetime call "$@" --no-config

When it happens

Trigger: Running `spacetime call --no-config` (nothing supplied: reports <database>) or `spacetime call mydb --no-config` (only the database: reports <function_name>); running call/subscribe outside any project directory with no spacetime.json and incomplete positionals.

Common situations: Scripts written for a configured project run on machines without the config; CI jobs that always pass --no-config but were authored expecting config-implied defaults; shell loops that sometimes produce an empty arguments list.

Understand the failure class

Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.

Related errors

• the following required arguments were not provided
• Invalid subcommand
• Cannot extract accessor name from query
• Cannot extract table name from query
• Cannot semijoin a table to itself

AI-assisted analysis of clockworklabs/SpacetimeDB@fdd647dfac (2026-08-20). Data as JSON: /api/errors/86ecea289a471f39. Report an issue: GitHub.

Appendix: source

Thrown at crates/cli/src/subcommands/db_arg_resolution.rs:120

fn single_config_server(config: &SpacetimeConfig) -> Option<String> {
    config
        .collect_all_targets_with_inheritance()
        .iter()
        .filter_map(|target| target.fields.get("server").and_then(|v| v.as_str()))
        .unique()
        .exactly_one()
        .ok()
        .map(str::to_string)
}

pub(crate) fn resolve_optional_database_parts(
    raw_parts: &[String],
    config_targets: Option<&[ConfigDbTarget]>,
    required_arg_name: &str,
    usage: &str,
) -> anyhow::Result<ResolvedDbArgs> {
    let require_arg = |name: &str| {
        anyhow::anyhow!(
            "the following required arguments were not provided:\n  <{}>\n\nUsage: {}",
            name,
            usage
        )
    };

    let Some(config_targets) = config_targets else {
        if raw_parts.len() < 2 {
            return if raw_parts.is_empty() {
                Err(require_arg("database"))
            } else {
                Err(require_arg(required_arg_name))
            };
        }
        return Ok(ResolvedDbArgs {
            database: raw_parts[0].clone(),
            server: None,
            remaining_args: raw_parts[1..].to_vec(),

View on GitHub (pinned to fdd647dfac)