clockworklabs/SpacetimeDB · error · anyhow::Error

Could not compute positional arguments during query planning

Error message

Could not compute positional arguments during query planning

What it means

Parameterized views with private arguments are backed by tables with an arg_hash column, and queries over them must be rewritten to select only rows matching the view's argument tuples. When a tuple field in the plan has no label (label_pos: None), the planner cannot map positional arguments to names and bails before optimization completes.

Source

Thrown at crates/physical-plan/src/plan.rs:546

                        ..
                    },
                    _,
                )
                | Self::HashJoin(
                    HashJoin {
                        rhs_field: TupleField { label_pos: None, .. },
                        ..
                    },
                    _,
                ) => {
                    unresolved_name = true;
                }
                _ => {}
            };
        });

        if unresolved_name {
            bail!("Could not compute positional arguments during query planning")
        }

        Ok(optimized)
    }

    /// If a view has private arguments, its backing table has an `arg_hash` column.
    /// This column tracks which rows belong to which argument tuple.
    ///
    /// As a result, queries over views cannot read the entire backing table.
    /// They must only select the rows corresponding to the view arguments used
    /// by each view reference. Hence we must add an implicit selection over
    /// these types of views.
    ///
    /// Ex.
    /// ```sql
    /// SELECT * FROM my_view
    /// ```
    ///

View on GitHub (pinned to 6dee26c6ef)

Solutions

1. Declare and reference the view's arguments by name (labeled parameters) instead of positionally.
2. Query the backing table directly with explicit filters if RLS and permissions permit.
3. Simplify the view: remove private arguments, or split the view so the problematic projection is not part of the subscribed query.

Example fix

-- before: positional view argument in the subscription
SELECT * FROM my_view(?);

-- after: named/labeled argument usage
SELECT * FROM my_view(arg => ?);

-- keep view arguments named and reference them by name:
--   CREATE VIEW v(x) AS ...;
--   SELECT * FROM v(arg => ?);   -- ok
-- avoid positional argument references in subscriptions over parameterized views

match compile_subscription(&sql, tx, auth) {
    Err(e) if e.to_string().contains("positional arguments") => {
        // rewrite using named view arguments or query the backing table
    }
    other => other,
}

When it happens

Trigger: Compiling a query or subscription over a parameterized view whose argument tuple fields cannot be resolved to labels during planning, leaving unresolved_name set.

Common situations: Subscribing to argument-parameterized views; changing a view's parameter list; schema/view definitions where arguments are used positionally rather than by name.

Related errors

• Subscriptions require indexes on join columns
• Index '${indexLabel}' on table '${tableLabel}' must define a
• Subscriptions must have at least one query
• Subscriptions must be SQL strings or typed queries
• Unsubscribe has already been called

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