Function trustfall_core::interpreter::helpers::check_adapter_invariants

pub fn check_adapter_invariants<'a, A: Adapter<'a>>(schema: &Schema, adapter: A)

Run a series of “dry run” checks to ensure an adapter is properly implemented.

Checks the following invariants about adapters:

• No panics when calling resolve_property() for all properties in the schema, as well as for the special __typename property that implicitly exists on all types.
• No panics when calling resolve_neighbors() edges in the schema that do not have required non-nullable edge parameters.
• No panics when calling resolve_coercion() for all interface implementations in the schema.
• resolve_property() produces a property value of FieldValue::Null for each context with a None active vertex.
• resolve_neighbors() produces an empty iterator of neighboring vertices for each context with a None active vertex.
• resolve_coercion() produces a false coercion outcome for each context with a None active vertex.
• resolve_property(), resolve_neighbors(), and resolve_coercion() yield contexts in the same relative order they received, without any reordering compared to the input order.

Failure to uphold any of the above invariants will cause a panic.

Example

This function would normally be used in a test case so that broken adapter invariants cause test failures:

#[test]
fn ensure_adapter_satisfies_invariants() {
    let (schema, adapter) = get_schema_and_adapter();
    check_adapter_invariants(&schema, adapter);
}

Limitations

Parameterized edges are checked using the default values of all their parameters. Nullable parameters are implicitly considered to have null as a default value.

Edges that take any non-nullable parameters without specified default values are not checked.

“My adapter fails this test, now what?”

Effectively all valid Trustfall adapters should uphold these invariants and pass these checks. In extremely rare cases, it’s possible that an adapter might work properly even if it cannot pass the checks in this function. However, doing so exposes those implementations to compatibility and correctness risks, and may cause difficult-to-debug bugs.

As a best practice, Adapter implementations should pass this function.