Schema Validation fails with panic `thread 'main' panicked at 'Expected ID field ... to be present on the model'`

Many database schemas that used to validate with 0 errors, now crash with a Rust Panic similar to this one:

Error: Schema parsing
thread 'main' panicked at 'Expected ID field rule_id to be present on the model', src/libcore/option.rs:1188:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:84
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1025
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:193
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:471
  11: rust_begin_unwind
             at src/libstd/panicking.rs:375
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:84
  13: core::option::expect_failed
             at src/libcore/option.rs:1188
  14: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
  15: prisma_models::fields::Fields::find_multipart_id
  16: once_cell::imp::OnceCell<T>::initialize::{{closure}}
  17: once_cell::imp::initialize_inner
  18: once_cell::imp::OnceCell<T>::initialize
  19: prisma_models::fields::Fields::id
  20: query_core::schema_builder::input_type_builder::InputTypeBuilderBase::where_unique_object_type
  21: query_core::schema_builder::object_type_builder::ObjectTypeBuilder::many_records_arguments
  22: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
  23: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  24: query_core::schema_builder::object_type_builder::ObjectTypeBuilder::new
  25: query_core::schema_builder::query_schema_builder::QuerySchemaBuilder::new
  26: prisma::cli::CliCommand::dmmf
  27: prisma::main::{{closure}}
  28: <std::future::GenFuture<T> as core::future::future::Future>::poll
  29: tokio::runtime::enter::Enter::block_on
  30: tokio::runtime::thread_pool::ThreadPool::block_on
  31: tokio::runtime::context::enter
  32: tokio::runtime::handle::Handle::enter
  33: prisma::main
  34: std::rt::lang_start::{{closure}}
  35: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  36: std::panicking::try::do_call
             at src/libstd/panicking.rs:292
  37: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:78
  38: std::panicking::try
             at src/libstd/panicking.rs:270
  39: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  40: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  41: main
  42: __libc_start_main
  43: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

(Internal Link: https://github.com/prisma/introspection-engine-output/commit/2356683bf674ef25defe7d1918e3b4f4c9a31735)

(Update: 90 schemas are affected)

[janpio]

Problem

Query Engine tries to create the “Input Types” by looking at @@id. It finds aId because that is a scalar fields, but does not find bId because that is not a scalar field but part of a relation. Then it panics and gives up.

Decision

Allow @@id to mention non scalar fields.

Temporary Guardrail

Drop the relation on the (currently) non scalar field to make it a scalar field, that is supported already. Write a comment “next” to the field to communicate to the user what happened.

[divyenduz]

@janpio test-utils failed at generate regarding this, as you can see, all the logs above point to a generate log file.

tl;dr; the relation to test-utils here is only that we found this out when trying test-utils out and mass generating. Query generator would have shown same results.