SeaQL/sea-orm · error

trait bound ensured arity

Error message

trait bound ensured arity

What it means

`DeleteOne::filter_by_ids` in `src/query/delete.rs:212` validates that the primary-key value tuples it just built match the entity's declared `PrimaryKeyArity`, and `.expect("trait bound ensured arity")` asserts this always holds. The trait bound on the method's generics is supposed to guarantee tuple/value arity agreement, so the panic signals a violated compile-time contract at runtime — typically from empty or malformed input value types.

Source

Thrown at src/query/delete.rs:212

    ///
    /// # Panics
    ///
    /// Should not panic.
    pub fn filter_by_ids<I>(mut self, values: I) -> Self
    where
        I: IntoIterator<Item = <E::PrimaryKey as PrimaryKeyTrait>::ValueType>,
    {
        self.query.cond_where(
            column_tuple_in_condition(
                &E::default().table_ref(),
                &E::primary_key_identity(),
                &values
                    .into_iter()
                    .map(|v| v.into_value_tuple())
                    .collect::<Vec<_>>(),
                DbBackend::Sqlite,
            )
            .expect("trait bound ensured arity"),
        );
        self
    }

    #[doc(hidden)]
    /// # Panics
    ///
    /// Panic if `ValueTuple` arity does not match primary key
    pub fn filter_by_value_tuples(mut self, values: &[ValueTuple], db_backend: DbBackend) -> Self {
        self.query.cond_where(
            column_tuple_in_condition(
                &E::default().table_ref(),
                &E::primary_key_identity(),
                values,
                db_backend,
            )
            .expect(""),
        );

View on GitHub (pinned to e29bcd1b41)

Solutions

  1. Pass primary-key values of the exact entity's `PrimaryKey::ValueType` (tuple of the right arity for composite keys).
  2. Update all generic call sites after changing a table's primary-key structure.
  3. Let the compiler infer types via `<Entity as PrimaryKeyTrait>::ValueType` instead of hardcoding `i32`/tuples.

Example fix

// before
delete_one_my_entity.filter_by_ids(vec![1]) // composite-key entity (id, org_id)
// after
use sea_orm::entity::prelude::*;
filter_by_ids(vec![(1, 42)]) // tuple matching PrimaryKeyArity::Two
Defensive patterns

Strategy: validation

Validate before calling

// Verify value arity matches PK arity before calling
let arity = <<E as EntityTrait>::PrimaryKey as PrimaryKeyTrait>::ValueType::ARITY;
assert!(!ids.is_empty());
debug_assert_eq!(ids.len(), 1); // for single-key entities using into_value_tuple

Type guard

fn ids_match_pk_arity<E: EntityTrait>(vals: &[ValueTuple]) -> bool {
    vals.iter().all(|v| v.arity() == <<E as EntityTrait>::PrimaryKey as PrimaryKeyTrait>::ValueType::ARITY)
}

Prevention

When it happens

Trigger: Calling `filter_by_ids` with values whose `into_value_tuple()` output arity does not match the entity's `PrimaryKeyArity` — e.g. passing a composite-key tuple to a single-key entity or vice versa through dynamic/generic code.

Common situations: Generic helpers that delete by ID across differently shaped entities; refactors that changed a table from single to composite primary key while callers still pass scalar ids; `DeriveValueType` wrappers altering tuple shape.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


AI-assisted analysis of SeaQL/sea-orm@e29bcd1b41 (2026-09-10). Data as JSON: /api/errors/7bd7a8afdca91953. Report an issue: GitHub.