clockworklabs/SpacetimeDB · error

internal error: function_name should be present after argume

Error message

internal error: function_name should be present after argument resolution

What it means

In `spacetime call` (crates/cli/src/subcommands/call.rs:82), after resolve_optional_database_parts succeeds, the code takes resolved.remaining_args.first() as the reducer name. Inspection of the resolver (crates/cli/src/subcommands/db_arg_resolution.rs:84-148) shows every success path returns at least one remaining arg when required_arg_name is enforced, so this bail is a defensive internal-invariant check that should be unreachable. Hitting it means argument resolution returned Ok with an empty remaining_args - a CLI bug, not a user input shape the resolver documents.

Source

Thrown at crates/cli/src/subcommands/call.rs:82

    let anon_identity = args.get_flag("anon_identity");
    let no_config = args.get_flag("no_config");

    let raw_parts: Vec<String> = args
        .get_many::<String>("call_parts")
        .map(|vals| vals.cloned().collect())
        .unwrap_or_default();

    let config_targets = load_config_db_targets(no_config)?;
    let resolved = resolve_optional_database_parts(
        &raw_parts,
        config_targets.as_deref(),
        "function_name",
        "spacetime call [database] <function_name> <arguments>... (or --no-config for legacy behavior)",
    )?;
    let reducer_procedure_name = resolved
        .remaining_args
        .first()
        .ok_or_else(|| anyhow::anyhow!("internal error: function_name should be present after argument resolution"))?;
    let call_arguments = resolved.remaining_args.iter().skip(1);
    let resolved_server = server.or(resolved.server.as_deref());

    let mut config = config;
    let conn = crate::api::Connection {
        host: config.get_host_url(resolved_server)?,
        auth_header: get_auth_header(&mut config, anon_identity, resolved_server, !force).await?,
        database_identity: database_identity(&config, &resolved.database, resolved_server).await?,
        database: resolved.database.clone(),
    };
    let api = ClientApi::new(conn);

    let database_identity = api.con.database_identity;
    let database = &api.con.database;

    let module_def: ModuleDef = api.module_def().await?.try_into()?;

    // Dot-qualified names (e.g. `lib.my_reducer`) route to submodules.

View on GitHub (pinned to 6dee26c6ef)

Solutions

1. Re-run with fully explicit arguments: `spacetime call <database> <function_name> <args...> --no-config` to bypass config-target resolution entirely.
2. Update to the latest CLI version in case the invariant break is already fixed.
3. If it reproduces, file an issue in the SpacetimeDB repo including the exact command line, spacetime.json (databases section), and CLI version - the 'internal error' prefix means the maintainers consider it unreachable.

Example fix

# before: triggers internal resolution bug
spacetime call my-reducer
# after: bypass config resolution with explicit parts
spacetime call my-db my-reducer '[]' --no-config

// Shell: require an explicit function name so resolution always has a remaining arg.
[ $# -ge 1 ] || { echo 'usage: spacetime call [database] <function_name> <args>...' >&2; exit 2; }
spacetime call "$@" --no-config

// Treat as a bug, not a retryable condition:
let out = run_spacetime(["call", ...]).context("spacetime call failed")?;
if out.contains("internal error: function_name should be present") {
    anyhow::bail!("CLI bug: please report at https://github.com/clockworklabs/SpacetimeDB/issues with this command line");
}

When it happens

Trigger: Running `spacetime call` in some boundary configuration where the resolver matches a config target but yields no remaining arguments - per the current resolver code there is no legal input that does this, so occurrences indicate a regression or an unusual invocation path (e.g. an empty-string positional argument edge case).

Common situations: New CLI versions where resolver behavior changed and this invariant broke; scripts passing empty or whitespace positional args; reporting a SpacetimeDB CLI bug with the exact command line.

Related errors

• could not serialize result: object had neither a `ok` nor an
• Tried to read ${n} byte(s) at relative offset ${this.offset}
• Cannot semijoin a table to itself
• Cannot extract table name from query
• Cannot extract accessor name from query

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